Re: [Xenomai] Linux port to ARM Allwinner A13

Re: [Xenomai] Linux port to ARM Allwinner A13

[Gilles Chanteperdrix]

On 02/26/2013 01:11 AM, Paul wrote:

> 
> Here is a first port for OLINUXINO A13 board.
> 
> http://www.crubille.lautre.net/xenomai_sun5i/ipipe-linuxsun5i-3.4.24.beta.patch
> 
> and apply the standart xenomai-2.6.2.1 procedure on a sunxi linux kernel 
> from :
> "git clone git://github.com/linux-sunxi/linux-sunxi.git -b sunxi-3.4"


Hi,

good news the I-pipe patch for ARM is ported to yet another board! If
you wish the patch to be distributed with Xenomai, please generate a
-pre and -post patches.

If you generate pre and post patches, we can update the I-pipe patch
with your pre and post patches remaining valid. If you do otherwise,
your patch will bitrot fast.

Since I have been talking about it so many times, I guess we should
provide a script to generate the -pre and -post patches.

> 
> I think that the A10/A13 port in the official linux tree is still too 
> unstable to port on it.
> 
> 
> The patch is a basic but functionnal version. I attempt to use priority 
> interrupt, but go in trouble.
> If i can have comments about this point?


Probably not much more than what you can find in the porting guide.

> 
> If somebody is interested in it for A10, it is very easy to adapt, and i 
> can do it and send the patch.
> 
> Paul Crubillé
> 
> ---------------------------------------------------------------------------------------------------
> 
> Running it, i get
> 
> 
> latency -t 2 -p 100
> == Sampling period: 100 us
> == Test mode: in-kernel timer handler
> == All results in microseconds
> RTT|  00:00:01  (in-kernel timer handler, 100 us period, priority 99)
> RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat 
> best|--lat worst
> RTD|      5.583|      6.265|     11.167|       0|     0|      5.583|    
>   11.167
> RTD|      6.125|      6.258|     10.917|       0|     0|      5.583|    
>   11.167
> RTD|      5.500|      6.270|     12.000|       0|     0|      5.500|    
>   12.000
> 
> 
> "lat worst" is mostly under 20 us but can go up for 30 ns.
> 
> latency  -p 100
> == Sampling period: 100 us
> == Test mode: periodic user-mode task
> == All results in microseconds
> warming up...
> RTT|  00:00:01  (periodic user-mode task, 100 us period, priority 99)
> RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat 
> best|--lat worst
> RTD|     11.999|     12.708|     21.333|       0|     0|     11.999|    
>   21.333
> RTD|     12.624|     12.791|     21.541|       0|     0|     11.999|    
>   21.541
> RTD|     12.458|     12.791|     26.458|       0|     0|     11.999|    
>   26.458
> 
> "lat worst" is mostly under 40 us but can go up for 80 ns.


Tests done without load are meaningless, try xeno-test or dohell.

-- 
                                                                Gilles.

[Xenomai] Linux port to ARM Allwinner A13

[Paul]

Here is a first port for OLINUXINO A13 board.

http://www.crubille.lautre.net/xenomai_sun5i/ipipe-linuxsun5i-3.4.24.beta.patch

and apply the standart xenomai-2.6.2.1 procedure on a sunxi linux kernel 
from :
"git clone git://github.com/linux-sunxi/linux-sunxi.git -b sunxi-3.4"

I think that the A10/A13 port in the official linux tree is still too 
unstable to port on it.


The patch is a basic but functionnal version. I attempt to use priority 
interrupt, but go in trouble.
If i can have comments about this point?

If somebody is interested in it for A10, it is very easy to adapt, and i 
can do it and send the patch.

Paul Crubillé

---------------------------------------------------------------------------------------------------

Running it, i get


latency -t 2 -p 100
== Sampling period: 100 us
== Test mode: in-kernel timer handler
== All results in microseconds
RTT|  00:00:01  (in-kernel timer handler, 100 us period, priority 99)
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat 
best|--lat worst
RTD|      5.583|      6.265|     11.167|       0|     0|      5.583|    
  11.167
RTD|      6.125|      6.258|     10.917|       0|     0|      5.583|    
  11.167
RTD|      5.500|      6.270|     12.000|       0|     0|      5.500|    
  12.000


"lat worst" is mostly under 20 us but can go up for 30 ns.

latency  -p 100
== Sampling period: 100 us
== Test mode: periodic user-mode task
== All results in microseconds
warming up...
RTT|  00:00:01  (periodic user-mode task, 100 us period, priority 99)
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat 
best|--lat worst
RTD|     11.999|     12.708|     21.333|       0|     0|     11.999|    
  21.333
RTD|     12.624|     12.791|     21.541|       0|     0|     11.999|    
  21.541
RTD|     12.458|     12.791|     26.458|       0|     0|     11.999|    
  26.458

"lat worst" is mostly under 40 us but can go up for 80 ns.

Re: [Xenomai] Linux port to ARM Allwinner A13

[Gilles Chanteperdrix]

On 03/11/2013 10:15 AM, Paul wrote:

> Hello,
> 
> Here are pre and post patch for xenomai on sun5i (allwinner A13). It
> should work for sun4i (allwinner A10) too, but is not tested for this
>  proc.
> 
> The tested kernels are
> 
> wget 
> https://github.com/linux-sunxi/linux-sunxi/archive/sunxi-v3.4.24-r1.tar.gz
>
> 


and

> wget 
> https://github.com/linux-sunxi/linux-sunxi/archive/sunxi-v3.4.24-r2.tar.gz




Fine,

> 


but the pre patch touches a lot of things which I believe it
should not be touching, like entry.S.

Is it because your patch is based on 3.2.24 and not 3.2.21? If that is
the case, the post patch should undo the changes made by the pre patch.

The coding style you use is not really the kernel coding style, see:
Documentation/CodingStyle

For sunxi_enable_irqdesc/sunxi_disable_irqdesc, you could use a switch
case, or even better, define a macro SW_INT_SRCPRIO_REG(n) that gives
the address of the nth register, and avoid the ifs completely.

You do not need to manually call enable_irqdesc for the timer irq, it
should be called automatically. Maybe your problem is that your
"pic_muter_init" function is called too late, if that is the case, you
should call it in the function which declares the Linux timer, this one
should be called early enough.

ipipe_ns_delay is ugly, you  can probably get away much more simply with
ipipe_tsc_get, or can not you simply wait for a PLL lock bit or
somehting? If you want to maintain ipipe_ns_delay, plase call it
ipipe_mach_something, and fix the coding style.

Please avoid dead code, and C++ comments. And the cartouches.

> 
> It implement priority interrupt masking.
> 
> I check the priority masking with a preempt test which is derived
> from the latency test: The real time task loop for 1/4 of its period
> reading and rereading the clock, so i get the min, avg and worst case
> that the task can be preempted while it is running.


> 
> If you are interested in this test, i can post it when I have
> modified the output messages.



I do not really understand. Why would it be more preempted in the first
1/4 of its period?


-- 
                                                                Gilles.

Re: [Xenomai] Linux port to ARM Allwinner A13

[Gilles Chanteperdrix]

On 03/11/2013 08:47 AM, Gilles Chanteperdrix wrote:

> On 03/11/2013 10:15 AM, Paul wrote:
> 
>> Hello,
>>
>> Here are pre and post patch for xenomai on sun5i (allwinner A13). It
>> should work for sun4i (allwinner A10) too, but is not tested for this
>>  proc.


Also, you seem to have duplicated the timer code, this should not be
needed, right?

-- 
                                                                Gilles.

Re: [Xenomai] Linux port to ARM Allwinner A13

[Paul]

Hello,

Here are pre and post patch for xenomai on sun5i (allwinner A13).
It should work for sun4i (allwinner A10) too, but is not tested for this 
proc.

The tested kernels are

wget 
https://github.com/linux-sunxi/linux-sunxi/archive/sunxi-v3.4.24-r1.tar.gz
and
wget 
https://github.com/linux-sunxi/linux-sunxi/archive/sunxi-v3.4.24-r2.tar.gz

It implement priority interrupt masking.

I check the priority masking with a preempt test which is derived from 
the latency test:
The real time task loop for 1/4 of its period reading and rereading the 
clock, so i get
the min, avg and worst case that the task can be preempted while it is 
running.

If you are interested in this test, i can post it when I have modified 
the output messages.

Paul Crubillé

-------------- next part --------------
A non-text attachment was scrubbed...
Name: pre.patch
Type: text/x-patch
Size: 9073 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20130311/7536eef3/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: post.patch
Type: text/x-patch
Size: 20084 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20130311/7536eef3/attachment-0001.bin>

Re: [Xenomai] Linux port to ARM Allwinner A13

[Paul]

Hello Gilles,

On 11/03/2013 08:47, Gilles Chanteperdrix wrote:
> On 03/11/2013 10:15 AM, Paul wrote:
>
>> Hello,
>>
>> Here are pre and post patch for xenomai on sun5i (allwinner A13). It
>> should work for sun4i (allwinner A10) too, but is not tested for this
>>   proc.
>>
>> The tested kernels are
>>
>> wget
>> https://github.com/linux-sunxi/linux-sunxi/archive/sunxi-v3.4.24-r1.tar.gz
>>
>>
>
> and
>
>> wget
>> https://github.com/linux-sunxi/linux-sunxi/archive/sunxi-v3.4.24-r2.tar.gz
>
>
>
> Fine,
>
>
> but the pre patch touches a lot of things which I believe it
> should not be touching, like entry.S.
>
> Is it because your patch is based on 3.2.24 and not 3.2.21? If that is
> the case, the post patch should undo the changes made by the pre patch.

The patch is based on 3.4.24 and the ipipe patch is noted to be a 3.4.6, 
but there is no such kernel for the sunxi.
So most of the patch fail are from the different linux version but 
curiously, vfp/entry.S are differents in the sunxi3.4.24 and in the 
vanill3.4.24..

>
> The coding style you use is not really the kernel coding style, see:
> Documentation/CodingStyle
OK, I would do it.
>
> For sunxi_enable_irqdesc/sunxi_disable_irqdesc, you could use a switch
> case, or even better, define a macro SW_INT_SRCPRIO_REG(n) that gives
> the address of the nth register, and avoid the ifs completely.
strange, but i copy/paste this part of code from the sunxi part (and 
found that bad):
My first idea was to mask, shift and use the result as index in a 
register index.
To stay close to the actual style, ok to use switch (it is not a so 
performance critical part).
>
> You do not need to manually call enable_irqdesc for the timer irq, it
> should be called automatically. Maybe your problem is that your
> "pic_muter_init" function is called too late, if that is the case, you
> should call it in the function which declares the Linux timer, this one
> should be called early enough.
I add this in an attempt to solve a problem which have nothing to do 
with it, and it stay here.
To be removed.
>
> ipipe_ns_delay is ugly, you  can probably get away much more simply with
> ipipe_tsc_get, or can not you simply wait for a PLL lock bit or
> somehting? If you want to maintain ipipe_ns_delay, plase call it
> ipipe_mach_something, and fix the coding style.
I dont know about ipipe_tsc_get, so i will test with it.
>
> Please avoid dead code, and C++ comments. And the cartouches.


FROM THE FOLLOWING MAIL:
> Also, you seem to have duplicated the timer code, this should not be
> needed, right?
The initialisation is very close, but i think the linux-sunxi 
timer_set_mode is broken.

Re: [Xenomai] Linux port to ARM Allwinner A13

[Paul]

Some precision and 2 small examples about a preempt test:

On 11/03/2013 08:47, Gilles Chanteperdrix wrote:
> On 03/11/2013 10:15 AM, Paul wrote:
>
>> Hello,
>>
>> ... ... ...
>>
>> I check the priority masking with a preempt test which is derived
>> from the latency test: The real time task loop for 1/4 of its period
>> reading and rereading the clock, so i get the min, avg and worst case
>> that the task can be preempted while it is running.
>
>> If you are interested in this test, i can post it when I have
>> modified the output messages.
>
>
> I do not really understand. Why would it be more preempted in the first
> 1/4 of its period?
>
>
No reason sure but -
  It can be preempted only while it is running, so between the time it 
is restarted after sleeping and before it go to sleep again.
Let it running 1/4 of the period is enough to catch lots of events if 
there is lots of irqs but not too much so linux, dohell or even xenomai 
tasks can run just a bit slower.


Here are some result i get (yes with the priority interrupt masking, and 
i am pretty sure it work - but the watchdog is on).
There is a dohell at the same time in the whole experiment and i start 
X11, stop it , restart it  ...


root@debian:/usr/xenomai/bin# 
/usr/src/build_xenomai/src/testsuite/preempt/preempt -p 111
== Sampling period: 111 us
== Test mode: periodic user-mode task
== All results in microseconds
warming up...
RTT|  00:00:01  (periodic user-mode task, 111 us period, priority 99)
RTH|----pre min|----pre avg|----pre max|-overrun|---msw|---pre 
best|--pre worst
RTD|      0.333|      0.374|      3.333|       0|     0|      
0.333|      3.333
RTD|      0.333|      0.374|     15.666|       0|     0|      0.333|     
15.666
---|-----------|-----------|-----------|--------|------|-------------------------

RTH|----pre min|----pre avg|----pre max|-overrun|---msw|---pre 
best|--pre worst
RTD|      0.333|      0.374|      3.708|       0|     0|      0.333|     
23.333
RTD|      0.333|      0.374|      3.874|       0|     0|      0.333|     
23.333
RTD|      0.333|      0.374|      3.541|       0|     0|      0.333|     
23.333
RTD|      0.333|      0.374|      3.916|       0|     0|      0.333|     
23.333
RTD|      0.333|      0.374|      3.541|       0|     0|      0.333|     
23.333
RTD|      0.333|      0.374|      3.583|       0|     0|      0.333|     
23.333
RTD|      0.333|      0.374|      3.499|       0|     0|      0.333|     
23.333
RTD|      0.333|      0.374|      3.833|       0|     0|      0.333|     
23.333
RTD|      0.333|      0.374|      3.791|       0|     0|      0.333|     
23.333
RTD|      0.333|      0.374|      3.666|       0|     0|      0.333|     
23.333
RTD|      0.333|      0.374|      3.833|       0|     0|      0.333|     
23.333
RTD|      0.333|      0.374|      3.749|       0|     0|      0.333|     
23.333
RTD|      0.333|      0.374|      3.749|       0|     0|      0.333|     
23.333
RTD|      0.333|      0.374|      3.624|       0|     0|      0.333|     
23.333
^C---|-----------|-----------|-----------|--------|------|-------------------------
RTS|      0.333|      0.374|     23.333|       0|     0|    
00:13:33/00:13:33


A second experiment, just setting the period to 100 (and the period for 
the watchdog is a multiple so 3/4 it never preempt the task:

/usr/src/build_xenomai/src/testsuite/preempt/preempt -p 100 -h
== Sampling period: 100 us
== Test mode: periodic user-mode task
== All results in microseconds
warming up...
RTT|  00:00:01  (periodic user-mode task, 100 us period, priority 99)
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat 
best|--lat worst
RTD|      0.333|      0.374|      0.749|       0|     0|      
0.333|      0.749
RTD|      0.333|      0.374|      2.749|       0|     0|      
0.333|      2.749
RTD|      0.333|      0.374|      0.708|       0|     0|      
0.333|      2.749
RTD|      0.333|      0.374|      0.833|       0|     0|      
0.333|      2.749
RTD|      0.333|      0.374|      0.708|       0|     0|      
0.333|      2.749
RTD|      0.333|      0.374|      0.833|       0|     0|      
0.333|      2.749
... ... ...
RTD|      0.333|      0.374|      3.749|       0|     0|      
0.333|      4.541
RTD|      0.333|      0.374|      4.166|       0|     0|      
0.333|      4.541
RTD|      0.333|      0.374|      3.541|       0|     0|      
0.333|      4.541
RTD|      0.333|      0.374|      3.791|       0|     0|      
0.333|      4.541
RTD|      0.333|      0.374|      3.666|       0|     0|      
0.333|      4.541
RTD|      0.333|      0.374|      4.416|       0|     0|      
0.333|      4.541
RTD|      0.333|      0.374|      3.791|       0|     0|      
0.333|      4.541
RTD|      0.333|      0.374|      3.874|       0|     0|      
0.333|      4.541
RTD|      0.333|      0.374|      3.749|       0|     0|      
0.333|      4.541
RTT|  00:04:13  (periodic user-mode task, 100 us period, priority 99)
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat 
best|--lat worst
RTD|      0.333|      0.374|      4.124|       0|     0|      
0.333|      4.541
^C---|--param|----range-|--samples
HSD|    min|   0 -  1 |      253
---|--param|----range-|--samples
HSD|    avg|   0 -  1 |  2530149
---|--param|----range-|--samples
HSD|    max|   0 -  1 |        3
HSD|    max|   1 -  2 |        1
HSD|    max|   2 -  3 |        3
HSD|    max|   3 -  4 |      186
HSD|    max|   4 -  5 |       60
HSH|--param|--samples-|--average--|---stddev--
HSS|    min|       253|      0.000|      0.000
HSS|    avg|   2530149|      0.000|      0.000
HSS|    max|       253|      3.182|      0.583
---|-----------|-----------|-----------|--------|------|-------------------------
RTS|      0.333|      0.374|      4.541|       0|     0|    
00:04:13/00:04:13

Re: [Xenomai] Linux port to ARM Allwinner A13

[Gilles Chanteperdrix]

On 03/11/2013 11:47 PM, Paul wrote:

> Some precision and 2 small examples about a preempt test:
> 
> On 11/03/2013 08:47, Gilles Chanteperdrix wrote:
>> On 03/11/2013 10:15 AM, Paul wrote:
>>
>>> Hello,
>>>
>>> ... ... ...
>>>
>>> I check the priority masking with a preempt test which is derived
>>> from the latency test: The real time task loop for 1/4 of its period
>>> reading and rereading the clock, so i get the min, avg and worst case
>>> that the task can be preempted while it is running.
>>
>>> If you are interested in this test, i can post it when I have
>>> modified the output messages.
>>
>>
>> I do not really understand. Why would it be more preempted in the first
>> 1/4 of its period?
>>
>>
> No reason sure but -
>   It can be preempted only while it is running, so between the time it 
> is restarted after sleeping and before it go to sleep again.
> Let it running 1/4 of the period is enough to catch lots of events if 
> there is lots of irqs but not too much so linux, dohell or even xenomai 
> tasks can run just a bit slower.
> 
> 
> Here are some result i get (yes with the priority interrupt masking, and 
> i am pretty sure it work - but the watchdog is on).
> There is a dohell at the same time in the whole experiment and i start 
> X11, stop it , restart it  ...
> 
> 
> root@debian:/usr/xenomai/bin# 
> /usr/src/build_xenomai/src/testsuite/preempt/preempt -p 111
> == Sampling period: 111 us
> == Test mode: periodic user-mode task
> == All results in microseconds
> warming up...
> RTT|  00:00:01  (periodic user-mode task, 111 us period, priority 99)
> RTH|----pre min|----pre avg|----pre max|-overrun|---msw|---pre 
> best|--pre worst
> RTD|      0.333|      0.374|      3.333|       0|     0|      
> 0.333|      3.333
> RTD|      0.333|      0.374|     15.666|       0|     0|      0.333|     
> 15.666
> ---|-----------|-----------|-----------|--------|------|-------------------------
> 
> RTH|----pre min|----pre avg|----pre max|-overrun|---msw|---pre 
> best|--pre worst
> RTD|      0.333|      0.374|      3.708|       0|     0|      0.333|     
> 23.333
> RTD|      0.333|      0.374|      3.874|       0|     0|      0.333|     
> 23.333
> RTD|      0.333|      0.374|      3.541|       0|     0|      0.333|     
> 23.333
> RTD|      0.333|      0.374|      3.916|       0|     0|      0.333|     
> 23.333
> RTD|      0.333|      0.374|      3.541|       0|     0|      0.333|     
> 23.333
> RTD|      0.333|      0.374|      3.583|       0|     0|      0.333|     
> 23.333
> RTD|      0.333|      0.374|      3.499|       0|     0|      0.333|     
> 23.333
> RTD|      0.333|      0.374|      3.833|       0|     0|      0.333|     
> 23.333
> RTD|      0.333|      0.374|      3.791|       0|     0|      0.333|     
> 23.333
> RTD|      0.333|      0.374|      3.666|       0|     0|      0.333|     
> 23.333
> RTD|      0.333|      0.374|      3.833|       0|     0|      0.333|     
> 23.333
> RTD|      0.333|      0.374|      3.749|       0|     0|      0.333|     
> 23.333
> RTD|      0.333|      0.374|      3.749|       0|     0|      0.333|     
> 23.333
> RTD|      0.333|      0.374|      3.624|       0|     0|      0.333|     
> 23.333
> ^C---|-----------|-----------|-----------|--------|------|-------------------------
> RTS|      0.333|      0.374|     23.333|       0|     0|    
> 00:13:33/00:13:33
> 
> 
> A second experiment, just setting the period to 100 (and the period for 
> the watchdog is a multiple so 3/4 it never preempt the task:


Looks only like pure luck to me. As you may or may not know, Xenomai
uses the timer in one-shot mode, so, the watchdog tick has no reason to
be aligned with your application timer. I would say the chances for your
task to be preempted by the watchdog tick while it is measuring is 1/4...


-- 
                                                                Gilles.

Re: [Xenomai] Linux port to ARM Allwinner A13

[Gilles Chanteperdrix]

On 03/12/2013 05:56 AM, Gilles Chanteperdrix wrote:

> On 03/11/2013 11:47 PM, Paul wrote:
> 
>> Some precision and 2 small examples about a preempt test:
>>
>> On 11/03/2013 08:47, Gilles Chanteperdrix wrote:
>>> On 03/11/2013 10:15 AM, Paul wrote:
>>>
>>>> Hello,
>>>>
>>>> ... ... ...
>>>>
>>>> I check the priority masking with a preempt test which is derived
>>>> from the latency test: The real time task loop for 1/4 of its period
>>>> reading and rereading the clock, so i get the min, avg and worst case
>>>> that the task can be preempted while it is running.
>>>
>>>> If you are interested in this test, i can post it when I have
>>>> modified the output messages.
>>>
>>>
>>> I do not really understand. Why would it be more preempted in the first
>>> 1/4 of its period?
>>>
>>>
>> No reason sure but -
>>   It can be preempted only while it is running, so between the time it 
>> is restarted after sleeping and before it go to sleep again.
>> Let it running 1/4 of the period is enough to catch lots of events if 
>> there is lots of irqs but not too much so linux, dohell or even xenomai 
>> tasks can run just a bit slower.
>>
>>
>> Here are some result i get (yes with the priority interrupt masking, and 
>> i am pretty sure it work - but the watchdog is on).
>> There is a dohell at the same time in the whole experiment and i start 
>> X11, stop it , restart it  ...
>>
>>
>> root@debian:/usr/xenomai/bin# 
>> /usr/src/build_xenomai/src/testsuite/preempt/preempt -p 111
>> == Sampling period: 111 us
>> == Test mode: periodic user-mode task
>> == All results in microseconds
>> warming up...
>> RTT|  00:00:01  (periodic user-mode task, 111 us period, priority 99)
>> RTH|----pre min|----pre avg|----pre max|-overrun|---msw|---pre 
>> best|--pre worst
>> RTD|      0.333|      0.374|      3.333|       0|     0|      
>> 0.333|      3.333
>> RTD|      0.333|      0.374|     15.666|       0|     0|      0.333|     
>> 15.666
>> ---|-----------|-----------|-----------|--------|------|-------------------------
>>
>> RTH|----pre min|----pre avg|----pre max|-overrun|---msw|---pre 
>> best|--pre worst
>> RTD|      0.333|      0.374|      3.708|       0|     0|      0.333|     
>> 23.333
>> RTD|      0.333|      0.374|      3.874|       0|     0|      0.333|     
>> 23.333
>> RTD|      0.333|      0.374|      3.541|       0|     0|      0.333|     
>> 23.333
>> RTD|      0.333|      0.374|      3.916|       0|     0|      0.333|     
>> 23.333
>> RTD|      0.333|      0.374|      3.541|       0|     0|      0.333|     
>> 23.333
>> RTD|      0.333|      0.374|      3.583|       0|     0|      0.333|     
>> 23.333
>> RTD|      0.333|      0.374|      3.499|       0|     0|      0.333|     
>> 23.333
>> RTD|      0.333|      0.374|      3.833|       0|     0|      0.333|     
>> 23.333
>> RTD|      0.333|      0.374|      3.791|       0|     0|      0.333|     
>> 23.333
>> RTD|      0.333|      0.374|      3.666|       0|     0|      0.333|     
>> 23.333
>> RTD|      0.333|      0.374|      3.833|       0|     0|      0.333|     
>> 23.333
>> RTD|      0.333|      0.374|      3.749|       0|     0|      0.333|     
>> 23.333
>> RTD|      0.333|      0.374|      3.749|       0|     0|      0.333|     
>> 23.333
>> RTD|      0.333|      0.374|      3.624|       0|     0|      0.333|     
>> 23.333
>> ^C---|-----------|-----------|-----------|--------|------|-------------------------
>> RTS|      0.333|      0.374|     23.333|       0|     0|    
>> 00:13:33/00:13:33
>>
>>
>> A second experiment, just setting the period to 100 (and the period for 
>> the watchdog is a multiple so 3/4 it never preempt the task:
> 
> 
> Looks only like pure luck to me. As you may or may not know, Xenomai
> uses the timer in one-shot mode, so, the watchdog tick has no reason to
> be aligned with your application timer. I would say the chances for your
> task to be preempted by the watchdog tick while it is measuring is 1/4...
> 
> 

Of course the difference if your application timer is a sub-multiple of
the watchdog timer is that the watchdog will always preempt your
application at the same moment, so, if it did not preempt it during the
first quarter of one period during the first second, it will never do.

-- 
                                                                Gilles.

Re: [Xenomai] Linux port to ARM Allwinner A13

[Gilles Chanteperdrix]

On 03/11/2013 11:29 PM, Paul wrote:

> Hello Gilles,
> 
> On 11/03/2013 08:47, Gilles Chanteperdrix wrote:
>> On 03/11/2013 10:15 AM, Paul wrote:
>>
>>> Hello,
>>>
>>> Here are pre and post patch for xenomai on sun5i (allwinner A13). It
>>> should work for sun4i (allwinner A10) too, but is not tested for this
>>>   proc.
>>>
>>> The tested kernels are
>>>
>>> wget
>>> https://github.com/linux-sunxi/linux-sunxi/archive/sunxi-v3.4.24-r1.tar.gz
>>>
>>>
>>
>> and
>>
>>> wget
>>> https://github.com/linux-sunxi/linux-sunxi/archive/sunxi-v3.4.24-r2.tar.gz
>>
>>
>>
>> Fine,
>>
>>
>> but the pre patch touches a lot of things which I believe it
>> should not be touching, like entry.S.
>>
>> Is it because your patch is based on 3.2.24 and not 3.2.21? If that is
>> the case, the post patch should undo the changes made by the pre patch.
> 
> The patch is based on 3.4.24 and the ipipe patch is noted to be a 3.4.6, 
> but there is no such kernel for the sunxi.
> So most of the patch fail are from the different linux version but 
> curiously, vfp/entry.S are differents in the sunxi3.4.24 and in the 
> vanill3.4.24..
> 
>>
>> The coding style you use is not really the kernel coding style, see:
>> Documentation/CodingStyle
> OK, I would do it.
>>
>> For sunxi_enable_irqdesc/sunxi_disable_irqdesc, you could use a switch
>> case, or even better, define a macro SW_INT_SRCPRIO_REG(n) that gives
>> the address of the nth register, and avoid the ifs completely.
> strange, but i copy/paste this part of code from the sunxi part (and 
> found that bad):
> My first idea was to mask, shift and use the result as index in a 
> register index.
> To stay close to the actual style, ok to use switch (it is not a so 
> performance critical part).
>>
>> You do not need to manually call enable_irqdesc for the timer irq, it
>> should be called automatically. Maybe your problem is that your
>> "pic_muter_init" function is called too late, if that is the case, you
>> should call it in the function which declares the Linux timer, this one
>> should be called early enough.
> I add this in an attempt to solve a problem which have nothing to do 
> with it, and it stay here.
> To be removed.
>>
>> ipipe_ns_delay is ugly, you  can probably get away much more simply with
>> ipipe_tsc_get, or can not you simply wait for a PLL lock bit or
>> somehting? If you want to maintain ipipe_ns_delay, plase call it
>> ipipe_mach_something, and fix the coding style.
> I dont know about ipipe_tsc_get, so i will test with it.
>>
>> Please avoid dead code, and C++ comments. And the cartouches.
> 
> 
> FROM THE FOLLOWING MAIL:
>> Also, you seem to have duplicated the timer code, this should not be
>> needed, right?
> The initialisation is very close, but i think the linux-sunxi 
> timer_set_mode is broken.


Hi Paul,

do you plan to send revised pre and post patches in say, the next few weeks?

Regards.

-- 
                                                                Gilles.

Re: [Xenomai] Linux port to ARM Allwinner A13

[kunming yang]

Hi,

I am now working on Cubieboard, which has the Soc A10. Can you send me the
patch for it? Thanks a lot!

Regards.