[Xenomai] [Xenomai-help] Latency calculation on da850 (Omap L138)

[Xenomai] [Xenomai-help] Latency calculation on da850 (Omap L138)

[GUGLIELMO NAVARRA]

Hello,
I ported i-pipe to the board da850 with TI L138 CPU.
I have no problems during startup, the system starts quietly.
I followed the guide http://www.xenomai.org/index.php/I-pipe-core:ArmPorting,
the only thing that I did not (because do not use ) are the changes to the GPIO module.
When I run latency program in "user-task period" mode, the latency shows great numbers and even negative,
which does not happen if i run latency in "in-kernel task period" mode, with more normal numbers.
Of course, before you run latency test, sending "echo 0 > /proc/xenomai/latency".

If I use cyclictest, the numbers are more correct. What could be the problem?
Is there any mistake I made or that I missed in porting?

Thanks

root@Board<mailto:root@Board> ~>./usr/xenomai/bin/latency -t 0
== Sampling period: 1000 us
== Test mode: periodic user-mode task
== All results in microseconds
warming up...
RTT|  00:00:01  (periodic user-mode task, 1000 us period, priority 99)
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
RTD| 370370.370| 918802.551|1418302.551|       0|     0| 370370.370|1418302.551
RTD| 370370.370| -81197.449| 418302.551|       0|     0| 370370.370|1418302.551
RTD| 370370.370|-1081197.448|-581697.448|       0|     0| 370370.370|1418302.551

RTD| 370370.370|-2081197.447|-1581697.448|       0|     0| 370370.370|1418302.55
1
RTD| 370370.370|1213769.849|1713269.849|       0|     0| 370370.370|1418302.551
RTD| 370370.370| 213769.850| 713269.849|       0|     0| 370370.370|1418302.551
RTD| 370370.370|-786230.150|-286730.150|       0|     0| 370370.370|1418302.551
RTD| 370370.370|-1786230.149|-1286730.149|       0|     0| 370370.370|1418302.55
1
RTD| 370370.370|1508737.148|2008237.147|       0|     0| 370370.370|1418302.551
RTD| 370370.370| 508737.148|1008237.148|       0|     0| 370370.370|1418302.551
RTD| 370370.370|-491262.851|   8237.148|       0|     0| 370370.370|1418302.551
RTD| 370370.370|-1491262.851|-991762.851|       0|     0| 370370.370|1418302.551

RTD| 370370.370|1803704.446|-1991762.850|       0|     0| 370370.370|1418302.551

RTD| 370370.370| 803704.447|1303204.446|       0|     0| 370370.370|1418302.551
RTD| 370370.370|-196295.553| 303204.447|       0|     0| 370370.370|1418302.551
?---|-----------|-----------|-----------|--------|------|-----------------------
--
RTS| 370370.370|-1786230.149|1418302.551|       0|     0|    00:00:15/00:00:15
root@Board<mailto:root@Board> ~>



root@Board<mailto:root@Board> ~>./usr/xenomai/bin/latency -t 1
== Sampling period: 1000 us
== Test mode: in-kernel periodic task
== All results in microseconds
warming up...
RTT|  00:00:01  (in-kernel periodic task, 1000 us period, priority 99)
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
RTD|     68.740|     77.299|    130.925|       0|     0|     68.740|    130.925
RTD|     67.554|     76.997|    132.776|       0|     0|     67.554|    132.776
RTD|     68.887|     77.536|    128.924|       0|     0|     67.554|    132.776
RTD|     65.368|     77.235|    136.405|       0|     0|     65.368|    136.405
RTD|     68.145|     77.162|    130.441|       0|     0|     65.368|    136.405
RTD|     68.144|     77.070|    133.292|       0|     0|     65.368|    136.405
RTD|     67.366|     77.239|    129.070|       0|     0|     65.368|    136.405
RTD|     67.514|     77.109|    128.921|       0|     0|     65.368|    136.405
RTD|     68.513|     77.471|    129.031|       0|     0|     65.368|    136.405
RTD|     66.994|     76.907|    132.920|       0|     0|     65.368|    136.405
RTD|     67.956|     77.237|    135.216|       0|     0|     65.368|    136.405
RTD|     67.141|     77.440|    138.104|       0|     0|     65.368|    138.104
RTD|     66.029|     77.157|    130.622|       0|     0|     65.368|    138.104
RTD|     67.436|     77.194|    128.843|       0|     0|     65.368|    138.104
RTD|     67.176|     77.353|    130.732|       0|     0|     65.368|    138.104
?---|-----------|-----------|-----------|--------|------|-----------------------
--
RTS|     65.368|     77.227|    138.104|       0|     0|    00:00:16/00:00:16
root@Board<mailto:root@Board> ~>



Startup kernel log:

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
Linux version 3.2.21-ipipe (omap@Sviluppo<mailto:omap@Sviluppo>) (gcc version 4.6.3 (Sourcery CodeBenc
h Lite 2012.03-57) ) #56 PREEMPT Sat Dec 15 12:11:05 CET 2012
CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177
CPU: VIVT data cache, VIVT instruction cache
Machine: DaVinci DA850/OMAP-L138/AM18x EVM
bootconsole [earlycon0] enabled
Memory policy: ECC disabled, Data cache writethrough
DaVinci da850/omap-l138 variant 0x0
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 8128
Kernel command line: mem=32M ip=192.168.1.141 console=ttyS2,115200n8 root=/dev/m
mcblk0p1 rootfstype=ext2 earlyprintk=serial,ttyS2,115200
PID hash table entries: 128 (order: -3, 512 bytes)
Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)
Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
Memory: 32MB = 32MB total
Memory: 27168k/27168k available, 5600k reserved, 0K highmem
Virtual kernel memory layout:
    vector  : 0xffff0000 - 0xffff1000   (   4 kB)
    fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
    vmalloc : 0xc2800000 - 0xfea00000   ( 962 MB)
    lowmem  : 0xc0000000 - 0xc2000000   (  32 MB)
    modules : 0xbf000000 - 0xc0000000   (  16 MB)
      .text : 0xc0008000 - 0xc0475978   (4535 kB)
      .init : 0xc0476000 - 0xc0499000   ( 140 kB)
      .data : 0xc049a000 - 0xc04c5ff8   ( 176 kB)
       .bss : 0xc04c601c - 0xc0526ce8   ( 388 kB)
NR_IRQS:245
 *** Davinci Clock Rate : 27000000 ***
 *** Clock Reload : 270000 ***
I-pipe, 27.000 MHz clocksource
Interrupt pipeline (release #1)
Console: colour dummy device 80x30
Calibrating delay loop... 167.32 BogoMIPS (lpj=836608)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
DaVinci: 144 gpio irqs
NET: Registered protocol family 16
bio: create slab <bio-0> at 0
pca953x 1-0020: failed reading register
pca953x: probe of 1-0020 failed with error -121
pca953x 1-0021: interrupt support not compiled in
Switching to clocksource ipipe_tsc
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 1024 (order: 1, 8192 bytes)
TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
TCP: Hash tables configured (established 1024 bind 1024)
TCP reno registered
UDP hash table entries: 256 (order: 0, 4096 bytes)
UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
EMAC: MII PHY configured, RMII PHY will not be functional
I-pipe: head domain Xenomai registered.
Xenomai: hal/arm started.
Xenomai: scheduling class idle registered.
Xenomai: scheduling class rt registered.
Xenomai: real-time nucleus v2.6.1 (Light Years Away) loaded.
Xenomai: debug mode enabled.
Xenomai: starting native API services.
Xenomai: starting POSIX services.
Xenomai: starting RTDM services.
msgmni has been set to 53
io scheduler noop registered (default)
start plist test
end plist test
Serial: 8250/16550 driver, 3 ports, IRQ sharing disabled
serial8250.0: ttyS0 at MMIO 0x1c42000 (irq = 25) is a 16550A
serial8250.0: ttyS1 at MMIO 0x1d0c000 (irq = 53) is a 16550A
ÿserial8250.0: ttyS2 at MMIO 0x1d0d000 (irq = 61) is a 16550A
console [ttyS2] enabled, bootconsole disabled
console [ttyS2] enabled, bootconsole disabled
brd: module loaded
davinci_mdio davinci_mdio.0: davinci mdio revision 1.5
davinci_mdio davinci_mdio.0: detected phy mask fffffffe
davinci_mdio.0: probed
davinci_mdio davinci_mdio.0: phy[0]: device 0:00, driver unknown
input: gpio-keys-polled as /devices/platform/gpio-keys-polled.1/input/input0
i2c /dev entries driver
davinci_mmc davinci_mmc.0: Using DMA, 4-bit mode
TCP cubic registered
NET: Registered protocol family 17
console [netcon0] enabled
netconsole: network logging started
davinci_mdio davinci_mdio.0: resetting idled controller
net eth0: attached PHY driver [Generic PHY] (mii_bus:phy_addr=0:00, id=7c0f1)
mmc0: new SD card at address e624
mmcblk0: mmc0:e624 SD128 120 MiB
 mmcblk0: p1
PHY: 0:00 - Link is Up - 100/Full
IP-Config: Guessing netmask 255.255.255.0
IP-Config: Complete:
     device=eth0, addr=192.168.1.141, mask=255.255.255.0, gw=255.255.255.255,
     host=192.168.1.141, domain=, nis-domain=(none),
     bootserver=255.255.255.255, rootserver=255.255.255.255, rootpath=
EXT2-fs (mmcblk0p1): warning: mounting unchecked fs, running e2fsck is recommend
ed
VFS: Mounted root (ext2 filesystem) on device 179:1.
Freeing init memory: 140K
init started: BusyBox v1.20.0 (2012-05-31 14:27:57 CEST)

Re: [Xenomai] [Xenomai-help] Latency calculation on da850 (Omap L138)

[Gilles Chanteperdrix]

On 12/15/2012 01:07 PM, GUGLIELMO NAVARRA wrote:

> Hello,
> I ported i-pipe to the board da850 with TI L138 CPU.
> I have no problems during startup, the system starts quietly.
> I followed the guide http://www.xenomai.org/index.php/I-pipe-core:ArmPorting,
> the only thing that I did not (because do not use ) are the changes to the GPIO module.
> When I run latency program in "user-task period" mode, the latency shows great numbers and even negative,
> which does not happen if i run latency in "in-kernel task period" mode, with more normal numbers.
> Of course, before you run latency test, sending "echo 0 > /proc/xenomai/latency".
> 
> If I use cyclictest, the numbers are more correct. What could be the problem?
> Is there any mistake I made or that I missed in porting?


You probably got the user-space "high resolution counter" (tsc)
emulation wrong. In order to check if the user-space tsc emulation runs
correctly, try the "tsc" test. The only reasons I already saw for the
emulation to run correctly in kernel-space but not in user-space are:
- you are passing the wrong physical address in the "struct
__ipipe_tscinfo" structure, this error only affects user-space
- the processor is configured to forbid access to the timers registers
in user-space, you have to change the configuration to allow it.

-- 
                                                                Gilles.

Re: [Xenomai] [Xenomai-help] Latency calculation on da850 (Omap L138)

[Gilles Chanteperdrix]

On 12/15/2012 02:31 PM, GUGLIELMO NAVARRA wrote:

> Thanks for your reply,
> my tsc_info definition is:
> 
> /*------------------------------------------------
>   Timer che utilizza IPIPE
>  -------------------------------------------------*/
> #ifdef CONFIG_IPIPE
> static struct __ipipe_tscinfo tsc_info = {
>         .type = IPIPE_TSC_TYPE_FREERUNNING,
>        .u = {
>                 {
>                         .mask = 0xffffffff,
>                 },
>         },
> };
> 
> static void l138_xenomai_tsc_init(void)
> {
>    struct timer_s *t = &timers[TID_CLOCKSOURCE];
>   
>    tsc_info.type = IPIPE_TSC_TYPE_FREERUNNING;
>    tsc_info.freq = l138_clock_tick_rate;

>    tsc_info.counter_vaddr = (unsigned long)(t->base + t->tim_off);

>    tsc_info.u.counter_paddr = DAVINCI_TIMER0_BASE + TIM12;


What about t->tim_off ?

>    //tsc_info.u.fr.counter = (unsigned *)(t->base + t->tim_off);
>    tsc_info.u.fr.mask = 0xffffffff;
>    __ipipe_tsc_register(&tsc_info);
> }
> 
> 
> Maybe I need to control access to the timer by user-space.
> I have already enabled FCSE in "guaranteed mode".


What processor core are you using? As explained in the documentation,
FCSE is only implemented for the arm920T, arm926EJ-S and Intel xscale cores.

> You tell me that I have to implement the part of the GPIO?


Definitely, if there are some multiplexed GPIOs and some drivers
existing using them. It is optional otherwise, but if you intend to
publish your patch (which I hope you do), it is better to implement the
GPIO demultiplexing, and even the hardening of gpiolib callbacks, in
case other users of the same platform need to use GPIOs.

Please no top-posting and no private mails.

-- 
                                                                Gilles.

Re: [Xenomai] [Xenomai-help] Latency calculation on da850 (Omap L138)

[Gilles Chanteperdrix]

On 12/15/2012 02:56 PM, Gilles Chanteperdrix wrote:

> On 12/15/2012 02:31 PM, GUGLIELMO NAVARRA wrote:
> 
>> Thanks for your reply,
>> my tsc_info definition is:
>>
>> /*------------------------------------------------
>>   Timer che utilizza IPIPE
>>  -------------------------------------------------*/
>> #ifdef CONFIG_IPIPE
>> static struct __ipipe_tscinfo tsc_info = {
>>         .type = IPIPE_TSC_TYPE_FREERUNNING,
>>        .u = {
>>                 {
>>                         .mask = 0xffffffff,
>>                 },
>>         },
>> };
>>
>> static void l138_xenomai_tsc_init(void)
>> {
>>    struct timer_s *t = &timers[TID_CLOCKSOURCE];
>>   
>>    tsc_info.type = IPIPE_TSC_TYPE_FREERUNNING;
>>    tsc_info.freq = l138_clock_tick_rate;
> 
>>    tsc_info.counter_vaddr = (unsigned long)(t->base + t->tim_off);
> 
>>    tsc_info.u.counter_paddr = DAVINCI_TIMER0_BASE + TIM12;
> 
> 
> What about t->tim_off ?


Also, if t->base can be something else than the result of an
ioremap(DAVINCI_TIMER0_BASE), then you should not hardcode
DAVINCI_TIMER0_BASE, as other boards may pass a different value, rather,
you should add a phys_base to "struct timer_s", and set it correctly for
each possible physical address.

-- 
                                                                Gilles.

Re: [Xenomai] [Xenomai-help] Latency calculation on da850 (Omap L138)

[GUGLIELMO NAVARRA]

Reply for FCSE: Omap L138 is based on ARM926ejs (FCSE supported)
Reply for tsc_info hardcode: 
The DAVINCI_TIMER0_BASE macro represents the physical address of the timer 0 (corrected), which is 64bit timer that i use (unchained mode) 32bit for clockevent (BOTTOM) and 32bit for clocksource (TOP) . 
Instead "t->base" represents the virtual address obtained from ioremap.
I made the changes that you asked me (GPIO and verify physical address), the result obtained is that the latency is not more negative but still very high.
Question : If the address in the tsc_info struct were incorrect, there would be a hang?

I noticed that if I read tracer with cat /proc/ipipe/trace/max, I find !
:|   #func                   2! 8895.678  __ipipe_restore_root_nosync+0x10 (__ipipe_preempt_schedule_irq+0x84)



root@Board ~>./usr/xenomai/bin/latency -t 0
== Sampling period: 1000 us
== Test mode: periodic user-mode task
== All results in microseconds
warming up...
RTT|  00:00:01  (periodic user-mode task, 1000 us period, priority 99)
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
RTD| 370370.370|-636832.807|-137332.808|       0|     0| 370370.370|-137332.808
RTD| 370370.370|-1636832.807|-1137332.807|       0|     0| 370370.370|-137332.80
8
RTD| 370370.370|1658134.490|-2137332.806|       0|     0| 370370.370|-137332.808
RTD| 370370.370| 658134.490|1157634.490|       0|     0| 370370.370|-137332.808
RTD| 370370.370|-341865.509| 157634.491|       0|     0| 370370.370|-137332.808
RTD| 370370.370|-1341865.508|-842365.509|       0|     0| 370370.370|-137332.808
RTD| 370370.370|1953101.788|-1842365.508|       0|     0| 370370.370|-137332.808
RTD| 370370.370| 953101.789|1452601.789|       0|     0| 370370.370|-137332.808
RTD| 370370.370| -46898.211| 452601.789|       0|     0| 370370.370|-137332.808
RTD| 370370.370|-1046898.210|-547398.210|       0|     0| 370370.370|-137332.808
RTD| 370370.370|-2046898.209|-1547398.210|       0|     0| 370370.370|-137332.80
8
RTD| 370370.370|1248069.087|1747569.087|       0|     0| 370370.370|-137332.808
RTD| 370370.370| 248069.088| 747569.088|       0|     0| 370370.370|-137332.808
RTD| 370370.370|-751930.912|-252430.912|       0|     0| 370370.370|-137332.808
RTD| 370370.370|-1751930.911|-1252430.911|       0|     0| 370370.370|-137332.80
8
RTD| 370370.370|1543036.386|2042536.385|       0|     0| 370370.370|-137332.808
RTD| 370370.370| 543036.386|1042536.386|       0|     0| 370370.370|-137332.808
RTD| 370370.370|-456963.613|  42536.387|       0|     0| 370370.370|-137332.808
RTD| 370370.370|-1456963.613|-957463.613|       0|     0| 370370.370|-137332.808
RTD| 370370.370|1838003.684|-1957463.612|       0|     0| 370370.370|-137332.808
?---|-----------|-----------|-----------|--------|------|-----------------------
--
RTS| 370370.370|-1546898.210|-137332.808|       0|     0|    00:00:21/00:00:21
root@Board ~>


Idea?


________________________________________
Da: Gilles Chanteperdrix [gilles.chanteperdrix@xenomai.org]
Inviato: sabato 15 dicembre 2012 15.06
A: guglielmo.navarra@studenti.uniparthenope.it
Cc: Xenomai
Oggetto: Re: [Xenomai] [Xenomai-help] Latency calculation on da850 (Omap L138)

On 12/15/2012 02:56 PM, Gilles Chanteperdrix wrote:

> On 12/15/2012 02:31 PM, GUGLIELMO NAVARRA wrote:
>
>> Thanks for your reply,
>> my tsc_info definition is:
>>
>> /*------------------------------------------------
>>   Timer che utilizza IPIPE
>>  -------------------------------------------------*/
>> #ifdef CONFIG_IPIPE
>> static struct __ipipe_tscinfo tsc_info = {
>>         .type = IPIPE_TSC_TYPE_FREERUNNING,
>>        .u = {
>>                 {
>>                         .mask = 0xffffffff,
>>                 },
>>         },
>> };
>>
>> static void l138_xenomai_tsc_init(void)
>> {
>>    struct timer_s *t = &timers[TID_CLOCKSOURCE];
>>
>>    tsc_info.type = IPIPE_TSC_TYPE_FREERUNNING;
>>    tsc_info.freq = l138_clock_tick_rate;
>
>>    tsc_info.counter_vaddr = (unsigned long)(t->base + t->tim_off);
>
>>    tsc_info.u.counter_paddr = DAVINCI_TIMER0_BASE + TIM12;
>
>
> What about t->tim_off ?


Also, if t->base can be something else than the result of an
ioremap(DAVINCI_TIMER0_BASE), then you should not hardcode
DAVINCI_TIMER0_BASE, as other boards may pass a different value, rather,
you should add a phys_base to "struct timer_s", and set it correctly for
each possible physical address.

--
                                                                Gilles.

Re: [Xenomai] [Xenomai-help] Latency calculation on da850 (Omap L138)

[Gilles Chanteperdrix]

On 12/15/2012 03:42 PM, GUGLIELMO NAVARRA wrote:

> Reply for FCSE: Omap L138 is based on ARM926ejs (FCSE supported) 
> Reply for tsc_info hardcode: The DAVINCI_TIMER0_BASE macro represents
> the physical address of the timer 0 (corrected), which is 64bit timer
> that i use (unchained mode) 32bit for clockevent (BOTTOM) and 32bit
> for clocksource (TOP) . Instead "t->base" represents the virtual
> address obtained from ioremap.


The Xenomai mailing list is an old style mailing list where we do not
top-post. So, please stop top-posting.

If the virtual address of the hardware counter is t->base + t->tim_off
and
t->base is the ioremap of DAVICIN_TIMER0_BASE then the counter physical
address is:
DAVINCI_TIMER0_BASE + t->tim_off

Hence my first question (which you did not answer):
"what about t->tim_off ?"

What I said was if other SOCs or other boards use different timer
configuration where t->base is not DAVINCI_TIMER0_BASE, then you should
not hardcode DAVINCI_TIMER0_BASE in the tsc physical address, yes this
will work in your case, but not for other possible configurations.

-- 
                                                                Gilles.

Re: [Xenomai] [Xenomai-help] Latency calculation on da850 (Omap L138)

[Gilles Chanteperdrix]

On 12/15/2012 03:42 PM, GUGLIELMO NAVARRA wrote:
> Question : If the address in the tsc_info struct were incorrect,

> there would be a hang?


If you are accessing another timer register, the processor will not
hang, what you read is simply not the hardware counter.

Anyway, I also asked you to run the "tsc" test, what does this test tell
you?

-- 
                                                                Gilles.

Re: [Xenomai] [Xenomai-help] Latency calculation on da850 (Omap L138)

[Gilles Chanteperdrix]

On 12/15/2012 04:45 PM, GUGLIELMO NAVARRA wrote:

> Da: Gilles Chanteperdrix [gilles.chanteperdrix@xenomai.org]
> Inviato: sabato 15 dicembre 2012 15.54
>> Anyway, I also asked you to run the "tsc" test, what does this test tell
>> you?


You are quoting the part about the tsc test, did you try and run it?

> 
> In the structure tsc_info must assign addresses (phy and virt) of timer assigned to clocksource or clockevent?



The tsc is a clocksource. If the tsc is based on a free running counter,
what should be accessed in user-space is the free running counter.
The counter which value changes at 27MHz.
The aim is to have an idea of the current time by reading this register.
I do not know how to explain this in any other way.

> I have assigned the offset of timer assigned to clockevent

> (base address is the same because the timer is 64-bit)

The tsc emulation code does not give a damn about any base address. It
simply needs the address of the counter. Nothing else, nothing more.

> 
> 
> static void l138_xenomai_tsc_init(void)
> {
>    struct davinci_soc_info *soc_info = &davinci_soc_info;
>    struct davinci_timer_instance *dtip = soc_info->timer_info->timers;
>    void __iomem *base;
>    base = ioremap(dtip[0].base, SZ_4K);
>    tsc_info.type = IPIPE_TSC_TYPE_FREERUNNING;
>    tsc_info.freq = l138_clock_tick_rate;
>    tsc_info.counter_vaddr = (unsigned long)(base + TIM12);
>    tsc_info.u.counter_paddr = dtip[0].base + TIM12;
>    tsc_info.u.fr.mask = 0xffffffff;
>    __ipipe_tsc_register(&tsc_info);
> }


If the registers are already ioremapped, please do not remap them a
second time. Also, if the tsc emulation was running correctly in
kernel-space, chances are the kernel-space virtual address was already
correct.

And please keep the mailing list in copy.

-- 
                                                                Gilles.

Re: [Xenomai] [Xenomai-help] Latency calculation on da850 (Omap L138)

[Gilles Chanteperdrix]

On 12/15/2012 01:07 PM, GUGLIELMO NAVARRA wrote:

> Hello,
> I ported i-pipe to the board da850 with TI L138 CPU.
> I have no problems during startup, the system starts quietly.
> I followed the guide http://www.xenomai.org/index.php/I-pipe-core:ArmPorting,
> the only thing that I did not (because do not use ) are the changes to the GPIO module.


Maybe the documentation is not clear enough, but you have to make the
changes to multiplexed GPIO irq handlers, otherwise all hell will break
loose when such an irq will happen, even in the absence of real-time
drivers.

Also, if your processor is an armv4 or armv5, you should consider
enabling the FCSE.

-- 
                                                                Gilles.

Re: [Xenomai] [Xenomai-help] Latency calculation on da850 (Omap L138)

[GUGLIELMO NAVARRA]

Da: Gilles Chanteperdrix [gilles.chanteperdrix@xenomai.org]
Inviato: sabato 15 dicembre 2012 15.54
> Anyway, I also asked you to run the "tsc" test, what does this test tell
> you?

In the structure tsc_info must assign addresses (phy and virt) of timer assigned to clocksource or clockevent?
I have assigned the offset of timer assigned to clockevent (base address is the same because the timer is 64-bit)


static void l138_xenomai_tsc_init(void)
{
struct davinci_soc_info *soc_info = &davinci_soc_info;
struct davinci_timer_instance *dtip = soc_info->timer_info->timers;
void __iomem *base;
base = ioremap(dtip[0].base, SZ_4K);
tsc_info.type = IPIPE_TSC_TYPE_FREERUNNING;
tsc_info.freq = l138_clock_tick_rate;
tsc_info.counter_vaddr = (unsigned long)(base + TIM12);
tsc_info.u.counter_paddr = dtip[0].base + TIM12;
tsc_info.u.fr.mask = 0xffffffff;
__ipipe_tsc_register(&tsc_info);
}



and in the board declaration:



static struct davinci_timer_instance da850_timer_instance[4] = {
{
.base = DA8XX_TIMER64P0_BASE,
.bottom_irq = IRQ_DA8XX_TINT12_0,
.top_irq = IRQ_DA8XX_TINT34_0,
},
{
.base = DA8XX_TIMER64P1_BASE,
.bottom_irq = IRQ_DA8XX_TINT12_1,
.top_irq = IRQ_DA8XX_TINT34_1,
},
{
.base = DA850_TIMER64P2_BASE,
.bottom_irq = IRQ_DA850_TINT12_2,
.top_irq = IRQ_DA850_TINT34_2,
},
{
.base = DA850_TIMER64P3_BASE,
.bottom_irq = IRQ_DA850_TINT12_3,
.top_irq = IRQ_DA850_TINT34_3,
},
};





Result not change

Re: [Xenomai] [Xenomai-help] Latency calculation on da850 (Omap L138)

[GUGLIELMO NAVARRA]

>GUGLIELMO NAVARRA [guglielmo.navarra@studenti.uniparthenope.it]
>Inviato: sabato 15 dicembre 2012 16.47
>A: xenomai@xenomai.org
>Oggetto: Re: [Xenomai] [Xenomai-help] Latency calculation on da850 (Omap L138)

>Da: Gilles Chanteperdrix [gilles.chanteperdrix@xenomai.org]
>Inviato: sabato 15 dicembre 2012 15.54
> Anyway, I also asked you to run the "tsc" test, what does this test tell
> you?

>In the structure tsc_info must assign addresses (phy and virt) of timer assigned to clocksource or clockevent?
>I have assigned the offset of timer assigned to clockevent (base address is the same because the timer is 64-bit)


>static void l138_xenomai_tsc_init(void)
>{
>struct davinci_soc_info *soc_info = &davinci_soc_info;
>struct davinci_timer_instance *dtip = soc_info->timer_info->timers;
>void __iomem *base;
>base = ioremap(dtip[0].base, SZ_4K);
>tsc_info.type = IPIPE_TSC_TYPE_FREERUNNING;
>tsc_info.freq = l138_clock_tick_rate;
>tsc_info.counter_vaddr = (unsigned long)(base + TIM12);
>tsc_info.u.counter_paddr = dtip[0].base + TIM12;
>tsc_info.u.fr.mask = 0xffffffff;
>__ipipe_tsc_register(&tsc_info);
>}


The changes above I changed the offset from TIM12 to TIM34 (clocksource) and when run latency shows good results:

root@Board ~>./usr/xenomai/bin/latency -t 0
== Sampling period: 1000 us
== Test mode: periodic user-mode task
== All results in microseconds
warming up...
RTT|  00:00:01  (periodic user-mode task, 1000 us period, priority 99)
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
RTD|     89.407|    102.592|    163.481|       0|     0|     89.407|    163.481
RTD|     91.518|    103.296|    161.370|       0|     0|     89.407|    163.481
RTD|     91.296|    103.185|    173.814|       0|     0|     89.407|    173.814
RTD|     88.962|    103.037|    165.555|       0|     0|     88.962|    173.814
RTD|     91.259|    102.370|    163.444|       0|     0|     88.962|    173.814
RTD|     91.962|    103.111|    162.555|       0|     0|     88.962|    173.814
RTD|     91.592|    103.148|    174.518|       0|     0|     88.962|    174.518
RTD|     91.370|    103.037|    173.444|       0|     0|     88.962|    174.518
RTD|     92.148|    102.629|    161.777|       0|     0|     88.962|    174.518
RTD|     92.851|    103.296|    167.370|       0|     0|     88.962|    174.518
RTD|     91.888|    103.148|    173.777|       0|     0|     88.962|    174.518
RTD|     91.629|    103.370|    176.629|       0|     0|     88.962|    176.629
RTD|     92.037|    102.814|    164.777|       0|     0|     88.962|    176.629
RTD|     92.518|    102.592|    160.851|       0|     0|     88.962|    176.629
RTD|     91.481|    103.148|    165.962|       0|     0|     88.962|    176.629
RTD|     91.037|    102.851|    161.740|       0|     0|     88.962|    176.629
RTD|     91.444|    102.666|    164.333|       0|     0|     88.962|    176.629
RTD|     91.407|    102.740|    164.037|       0|     0|     88.962|    176.629
RTD|     78.481|    102.962|    164.703|       0|     0|     78.481|    176.629
RTD|     92.481|    103.333|    163.481|       0|     0|     78.481|    176.629
RTD|     91.999|    102.814|    167.074|       0|     0|     78.481|    176.629
RTT|  00:00:22  (periodic user-mode task, 1000 us period, priority 99)
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
RTD|     91.222|    103.074|    169.481|       0|     0|     78.481|    176.629
RTD|     91.518|    103.444|    164.037|       0|     0|     78.481|    176.629
RTD|     92.074|    103.296|    167.185|       0|     0|     78.481|    176.629
?---|-----------|-----------|-----------|--------|------|-----------------------
--
RTS|     78.481|    102.962|    176.629|       0|     0|    00:00:24/00:00:24
root@Board ~>


Thank you for your advice Gilles. 
Now I will test hard with a load.