Re: [Xenomai-core] [RFC] Port to AT91SAM9G45

2012-02-07 Thread Gregory CLEMENT 
On 02/07/2012 04:55 PM, Gilles Chanteperdrix wrote:
> On 02/07/2012 02:01 PM, Gregory CLEMENT wrote:
>> Hello,
>>
>> I've done the port for AT91SAM9G45 on a AT91SAM9M10G45-EK board. The
>> following patch have to be applied on top of the
>> adeos-ipipe-2.6.38.8-arm-1.18-04.patch patch.
>>
>> I also ran latency test under heavy stress using:
>> - hackbench to stress the scheduler
>> - netcat to stress the Ethernet interface and generate a lot of interrupts
>> - ls and dd( reading a /dev/mtdblock and writing on a tmpfs) for global 
>> stress
>>
>> I join the results I had after running each latency test during 10 hours.
>>
>> If the results I get seem the correct could you apply this patch in
>> Xenomai?
>>
>> Should I also submit this patch to adeos project?
> 
> We will merge this patch in the adeos patch, yes. Thanks. Note that
> xenomai-2.6.0 provides a "dohell" command in order to generate some
> load, and a "xeno-test" script which runs latency under dohell load.
> 


Thanks for the pointer. Theses scripts cover almost all I've done,
expect the case involving 'dd'. I chose to read the flash and no to
write on a mount point located in flash to no "wear" it.
Next time I will use these scripts and just tune them for my need.

> Are the results obtained with or without the FCSE option enabled?
> 

They are obtained with the FCSE option enabled. Do you want the kernel
config file ?

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
+33 602 196 044

___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

[Xenomai-core] [RFC] Port to AT91SAM9G45

2012-02-07 Thread Gregory CLEMENT 
Hello,

I've done the port for AT91SAM9G45 on a AT91SAM9M10G45-EK board. The
following patch have to be applied on top of the
adeos-ipipe-2.6.38.8-arm-1.18-04.patch patch.

I also ran latency test under heavy stress using:
- hackbench to stress the scheduler
- netcat to stress the Ethernet interface and generate a lot of interrupts
- ls and dd( reading a /dev/mtdblock and writing on a tmpfs) for global stress

I join the results I had after running each latency test during 10 hours.

If the results I get seem the correct could you apply this patch in
Xenomai?

Should I also submit this patch to adeos project?

Regards
-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
+33 602 196 044
>From 39a2100b7bc34755d22409ea1f0d23a94bd99ed8 Mon Sep 17 00:00:00 2001
From: Gregory CLEMENT 
Date: Sat, 29 Oct 2011 19:16:57 +0200
Subject: [PATCH 1/1] Adeos / Xenomai port for AT91SAM9M10G45-EK


Signed-off-by: Gregory CLEMENT 
---
 arch/arm/mach-at91/Makefile|1 +
 arch/arm/mach-at91/at91_ipipe_time.c   |   23 +
 arch/arm/mach-at91/at91sam9g45.c   |   50 +++-
 arch/arm/mach-at91/include/mach/hardware.h |2 +
 4 files changed, 68 insertions(+), 8 deletions(-)

diff --git a/arch/arm/mach-at91/Makefile b/arch/arm/mach-at91/Makefile
index 5e11f9f..99c487d 100644
--- a/arch/arm/mach-at91/Makefile
+++ b/arch/arm/mach-at91/Makefile
@@ -105,4 +105,5 @@ obj-$(CONFIG_ARCH_AT91SAM9263)	+= at91_ipipe_time.o
 obj-$(CONFIG_ARCH_AT91SAM9RL)	+= at91_ipipe_time.o
 obj-$(CONFIG_ARCH_AT91SAM9G20)  += at91_ipipe_time.o
 obj-$(CONFIG_ARCH_AT91X40)	+= at91_ipipe_time.o
+obj-$(CONFIG_ARCH_AT91SAM9G45)	+= at91_ipipe_time.o
 endif
diff --git a/arch/arm/mach-at91/at91_ipipe_time.c b/arch/arm/mach-at91/at91_ipipe_time.c
index b0aa6a4..2e97a28 100644
--- a/arch/arm/mach-at91/at91_ipipe_time.c
+++ b/arch/arm/mach-at91/at91_ipipe_time.c
@@ -6,6 +6,9 @@
  * Adaptation to AT91SAM926x:
  * Copyright (C) 2007 Gregory CLEMENT, Adeneo
  *
+ * Adaptation to AT91SAM9G45:
+ * Copyright (C) 2011 Gregory CLEMENT, Free Electrons
+ *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2 as
  * published by the Free Software Foundation.
@@ -55,6 +58,10 @@
 #define AT91_ID_TC0 AT91X40_ID_TC0
 #define AT91_ID_TC1 AT91X40_ID_TC1
 #define AT91_ID_TC2 AT91X40_ID_TC2
+#elif defined(CONFIG_ARCH_AT91SAM9G45)
+#define AT91_ID_TC0 AT91SAM9G45_ID_TCB
+#define AT91_ID_TC1 AT91SAM9G45_ID_TCB
+#define AT91_ID_TC2 AT91SAM9G45_ID_TCB
 #else
 #error "AT91 processor unsupported by Adeos"
 #endif
@@ -146,12 +153,14 @@ at91_tc_set_mode(enum clock_event_mode mode, struct clock_event_device *dev)
 	if (mode == CLOCK_EVT_MODE_PERIODIC) {
 		unsigned long v;
 
-#ifndef CONFIG_ARCH_AT91SAM9263
-		clk_enable(clk_get(NULL, "tc"
-   __stringify(CONFIG_IPIPE_AT91_TC) "_clk"));
-#else /* AT91SAM9263 */
+#ifdef CONFIG_ARCH_AT91SAM9263
 		clk_enable(clk_get(NULL, "tcb_clk"));
-#endif /* AT91SAM9263 */
+#elif CONFIG_ARCH_AT91SAM9G45
+		clk_enable(clk_get(NULL, "tcb0_clk"));
+#else /* AT91SAM9263 and AT91SAM9G45*/
+		clk_enable(clk_get(NULL, "tc"
+		   __stringify(CONFIG_IPIPE_AT91_TC) "_clk"));
+#endif 
 
 		/* No Sync. */
 		at91_tc_write(AT91_TC_BCR, 0);
@@ -246,7 +255,7 @@ void __init at91_timer_init(void)
 	(void) at91_sys_read(AT91_ST_SR);	/* Clear any pending interrupts */
 #elif defined(CONFIG_ARCH_AT91SAM9260) || defined(CONFIG_ARCH_AT91SAM9261) \
 	|| defined(CONFIG_ARCH_AT91SAM9263) || defined(CONFIG_ARCH_AT91SAM9RL) \
-	|| defined(CONFIG_ARCH_AT91SAM9G20)
+	|| defined(CONFIG_ARCH_AT91SAM9G20) || defined(CONFIG_ARCH_AT91SAM9G45)
 	at91_sys_write(AT91_PIT_MR, 0);
 
 	/* Clear any pending interrupts */
@@ -303,7 +312,7 @@ void __init at91_timer_init(void)
 struct sys_timer at91rm9200_timer = {
 #elif defined(CONFIG_ARCH_AT91SAM9260) || defined(CONFIG_ARCH_AT91SAM9261) \
 	|| defined(CONFIG_ARCH_AT91SAM9263) || defined(CONFIG_ARCH_AT91SAM9RL) \
-	|| defined(CONFIG_ARCH_AT91SAM9G20)
+	|| defined(CONFIG_ARCH_AT91SAM9G20) || defined(CONFIG_ARCH_AT91SAM9G45)
 struct sys_timer at91sam926x_timer = {
 #elif defined(CONFIG_ARCH_AT91X40)
 struct sys_timer at91x40_timer = {
diff --git a/arch/arm/mach-at91/at91sam9g45.c b/arch/arm/mach-at91/at91sam9g45.c
index c67b47f..d0ef1af 100644
--- a/arch/arm/mach-at91/at91sam9g45.c
+++ b/arch/arm/mach-at91/at91sam9g45.c
@@ -31,7 +31,16 @@ static struct map_desc at91sam9g45_io_desc[] __initdata = {
 		.pfn		= __phys_to_pfn(AT91_BASE_SYS),
 		.length		= SZ_16K,
 		.type		= MT_DEVICE,
-	}, {
+	},
+#ifdef CONFIG_IPIPE
+	{
+		.virtual	= AT91_VA_BASE_TCB0,
+		.pfn		= __phys_to_pfn(AT91_BASE_TCB0),
+		.length		= SZ_16K,
+		.type		= MT_DEVICE,
+	},
+#endif /* CONFIG_IPIPE */
+	{
 		.virtual	= AT91_IO_VIRT_BASE - AT91

[Xenomai-core] Adeos patch to make RTAI works on AT91SAM926x

2007-10-09 Thread Gregory CLEMENT 
   : "r" (p), "Ir" (old), "r" (new)\
+   : "cc");\
+   } while(res);   \
+   break;  \
+   default:\
+   __bad_cmpxchg(p, sizeof(res));  \
+   oldval = 0; \
+   break;  \
+   }   \
+   oldval; \
+})
+
+#else
+#include 
+#endif
+
 #endif /* __ASSEMBLY__ */

 #define arch_align_stack(x) (x)
diff -NaurdpbB -X nodiff
linux-2.6.20.13-clean/include/asm-arm/thread_info.h
linux-2.6.20.13/include/asm-arm/thread_info.h
--- linux-2.6.20.13-clean/include/asm-arm/thread_info.h 2007-07-12
11:44:04.0 +0200
+++ linux-2.6.20.13/include/asm-arm/thread_info.h   2007-07-12
09:34:28.0 +0200
@@ -143,6 +143,7 @@ extern void iwmmxt_task_switch(struct th
 #define TIF_NOTIFY_RESUME  0
 #define TIF_SIGPENDING 1
 #define TIF_NEED_RESCHED   2
+#define TIF_RESTORE_SIGMASK6   /* restore signal mask in do_signal() */
 #define TIF_SYSCALL_TRACE  8
 #define TIF_POLLING_NRFLAG 16
 #define TIF_USING_IWMMXT   17
@@ -155,6 +156,7 @@ extern void iwmmxt_task_switch(struct th
 #define _TIF_NOTIFY_RESUME (1 << TIF_NOTIFY_RESUME)
 #define _TIF_SIGPENDING(1 << TIF_SIGPENDING)
 #define _TIF_NEED_RESCHED  (1 << TIF_NEED_RESCHED)
+#define _TIF_RESTORE_SIGMASK   (1<evhand[event])) {
+   return ((int (*)(unsigned long, void *))handler)(event, data);
+   } else {
+
struct ipipe_domain *start_domain, *this_domain, *next_domain;
ipipe_event_handler_t evhand;
struct list_head *pos, *npos;
@@ -677,7 +686,7 @@ int fastcall __ipipe_dispatch_event (uns
ipipe_unlock_cpu(flags);

return !propagate;
-}
+} }

 /*
  * __ipipe_dispatch_wired -- Wired interrupt dispatcher. Wired
@@ -1443,3 +1452,4 @@ EXPORT_SYMBOL(ipipe_get_ptd);
 EXPORT_SYMBOL(ipipe_set_irq_affinity);
 EXPORT_SYMBOL(ipipe_send_ipi);
 EXPORT_SYMBOL(__ipipe_schedule_irq);
+EXPORT_SYMBOL(__ipipe_sync_stage);
diff -NaurdpbB -X nodiff linux-2.6.20.13-clean/kernel/sched.c
linux-2.6.20.13/kernel/sched.c
--- linux-2.6.20.13-clean/kernel/sched.c2007-07-12 11:44:04.0 
+0200
+++ linux-2.6.20.13/kernel/sched.c  2007-08-23 13:44:00.0 +0200
@@ -1845,6 +1845,12 @@ context_switch(struct rq *rq, struct tas
struct mm_struct *mm = next->mm;
struct mm_struct *oldmm = prev->active_mm;

+#ifdef CONFIG_IPIPE
+if (!rq) {
+   switch_mm(oldmm, next->active_mm, next);
+   if (!mm) enter_lazy_tlb(oldmm, next);
+} else {
+#endif
if (!mm) {
next->active_mm = oldmm;
atomic_inc(&oldmm->mm_count);
@@ -1857,6 +1863,9 @@ context_switch(struct rq *rq, struct tas
WARN_ON(rq->prev_mm);
rq->prev_mm = oldmm;
}
+#ifdef CONFIG_IPIPE
+}
+#endif
/*
 * Since the runqueue lock will be released by the next
 * task (which is an invalid locking op but in the case
@@ -1864,12 +1873,19 @@ context_switch(struct rq *rq, struct tas
 * do an early lockdep release here:
 */
 #ifndef __ARCH_WANT_UNLOCKED_CTXSW
+#ifdef CONFIG_IPIPE
+if (rq)
+#endif /* CONFIG_IPIPE */
spin_release(&rq->lock.dep_map, 1, _THIS_IP_);
 #endif

/* Here we just switch the register state and the stack. */
switch_to(prev, next, prev);

+#ifdef CONFIG_IPIPE
+   current->ptd[IPIPE_ROOT_NPTDKEYS - 1] = prev;
+#endif /* CONFIG_IPIPE */
+
return prev;
 }

@@ -3567,6 +3583,9 @@ switch_tasks:
barrier();
if (task_hijacked(prev))
return;
+   #ifdef CONFIG_IPIPE
+   __ipipe_dispatch_event(IPIPE_FIRST_EVENT - 2, 0);
+   #endif /* CONFIG_IPIPE */
/*
 * this_rq must be evaluated again because prev may have moved
     * CPUs since it called schedule(), thus the 'rq' on its stack
@@ -7115,6 +7134,7 @@ int ipipe_reenter_root (struct task_stru
return 0;
 }

+EXPORT_SYMBOL(context_switch);
 EXPORT_SYMBOL(ipipe_reenter_root);

 #endif /* CONFIG_IPIPE */


-- 
Gregory CLEMENT
Adeneo
Adetel Group
2, chemin du Ruisseau
69134 ECULLY - FRANCE
Tél. : +33 (0)4 72 18 08 40 - Fax : +33 (0)4 72 18 08 41

www.adetelgroup.com

___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

[Xenomai-core] Adeos patch to make RTAI works on AT91SAM926x

2007-10-09 Thread Gregory CLEMENT 
   : "r" (p), "Ir" (old), "r" (new)\
+   : "cc");\
+   } while(res);   \
+   break;  \
+   default:\
+   __bad_cmpxchg(p, sizeof(res));  \
+   oldval = 0; \
+   break;  \
+   }   \
+   oldval; \
+})
+
+#else
+#include 
+#endif
+
 #endif /* __ASSEMBLY__ */

 #define arch_align_stack(x) (x)
diff -NaurdpbB -X nodiff
linux-2.6.20.13-clean/include/asm-arm/thread_info.h
linux-2.6.20.13/include/asm-arm/thread_info.h
--- linux-2.6.20.13-clean/include/asm-arm/thread_info.h 2007-07-12
11:44:04.0 +0200
+++ linux-2.6.20.13/include/asm-arm/thread_info.h   2007-07-12
09:34:28.0 +0200
@@ -143,6 +143,7 @@ extern void iwmmxt_task_switch(struct th
 #define TIF_NOTIFY_RESUME  0
 #define TIF_SIGPENDING 1
 #define TIF_NEED_RESCHED   2
+#define TIF_RESTORE_SIGMASK6   /* restore signal mask in do_signal() */
 #define TIF_SYSCALL_TRACE  8
 #define TIF_POLLING_NRFLAG 16
 #define TIF_USING_IWMMXT   17
@@ -155,6 +156,7 @@ extern void iwmmxt_task_switch(struct th
 #define _TIF_NOTIFY_RESUME (1 << TIF_NOTIFY_RESUME)
 #define _TIF_SIGPENDING(1 << TIF_SIGPENDING)
 #define _TIF_NEED_RESCHED  (1 << TIF_NEED_RESCHED)
+#define _TIF_RESTORE_SIGMASK   (1<evhand[event])) {
+   return ((int (*)(unsigned long, void *))handler)(event, data);
+   } else {
+
struct ipipe_domain *start_domain, *this_domain, *next_domain;
ipipe_event_handler_t evhand;
struct list_head *pos, *npos;
@@ -677,7 +686,7 @@ int fastcall __ipipe_dispatch_event (uns
ipipe_unlock_cpu(flags);

return !propagate;
-}
+} }

 /*
  * __ipipe_dispatch_wired -- Wired interrupt dispatcher. Wired
@@ -1443,3 +1452,4 @@ EXPORT_SYMBOL(ipipe_get_ptd);
 EXPORT_SYMBOL(ipipe_set_irq_affinity);
 EXPORT_SYMBOL(ipipe_send_ipi);
 EXPORT_SYMBOL(__ipipe_schedule_irq);
+EXPORT_SYMBOL(__ipipe_sync_stage);
diff -NaurdpbB -X nodiff linux-2.6.20.13-clean/kernel/sched.c
linux-2.6.20.13/kernel/sched.c
--- linux-2.6.20.13-clean/kernel/sched.c2007-07-12 11:44:04.0 
+0200
+++ linux-2.6.20.13/kernel/sched.c  2007-08-23 13:44:00.0 +0200
@@ -1845,6 +1845,12 @@ context_switch(struct rq *rq, struct tas
struct mm_struct *mm = next->mm;
struct mm_struct *oldmm = prev->active_mm;

+#ifdef CONFIG_IPIPE
+if (!rq) {
+   switch_mm(oldmm, next->active_mm, next);
+   if (!mm) enter_lazy_tlb(oldmm, next);
+} else {
+#endif
if (!mm) {
next->active_mm = oldmm;
atomic_inc(&oldmm->mm_count);
@@ -1857,6 +1863,9 @@ context_switch(struct rq *rq, struct tas
WARN_ON(rq->prev_mm);
rq->prev_mm = oldmm;
}
+#ifdef CONFIG_IPIPE
+}
+#endif
/*
 * Since the runqueue lock will be released by the next
 * task (which is an invalid locking op but in the case
@@ -1864,12 +1873,19 @@ context_switch(struct rq *rq, struct tas
 * do an early lockdep release here:
 */
 #ifndef __ARCH_WANT_UNLOCKED_CTXSW
+#ifdef CONFIG_IPIPE
+if (rq)
+#endif /* CONFIG_IPIPE */
spin_release(&rq->lock.dep_map, 1, _THIS_IP_);
 #endif

/* Here we just switch the register state and the stack. */
switch_to(prev, next, prev);

+#ifdef CONFIG_IPIPE
+   current->ptd[IPIPE_ROOT_NPTDKEYS - 1] = prev;
+#endif /* CONFIG_IPIPE */
+
return prev;
 }

@@ -3567,6 +3583,9 @@ switch_tasks:
barrier();
if (task_hijacked(prev))
return;
+   #ifdef CONFIG_IPIPE
+   __ipipe_dispatch_event(IPIPE_FIRST_EVENT - 2, 0);
+   #endif /* CONFIG_IPIPE */
/*
 * this_rq must be evaluated again because prev may have moved
     * CPUs since it called schedule(), thus the 'rq' on its stack
@@ -7115,6 +7134,7 @@ int ipipe_reenter_root (struct task_stru
return 0;
 }

+EXPORT_SYMBOL(context_switch);
 EXPORT_SYMBOL(ipipe_reenter_root);

 #endif /* CONFIG_IPIPE */


-- 
Gregory CLEMENT
Adeneo
Adetel Group
2, chemin du Ruisseau
69134 ECULLY - FRANCE
Tél. : +33 (0)4 72 18 08 40 - Fax : +33 (0)4 72 18 08 41

www.adetelgroup.com

___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

[Xenomai-core] Fwd: RTAI and Xenomai latency in kernel mode on AT91SAM9261-EK

2007-10-09 Thread Gregory CLEMENT 
-- Forwarded message --
From: Gregory CLEMENT <[EMAIL PROTECTED]>
Date: 9 oct. 2007 21:07
Subject: Re: [Xenomai-core] RTAI and Xenomai latency in kernel mode on
AT91SAM9261-EK
To: Jan Kiszka <[EMAIL PROTECTED]>


2007/10/9, Jan Kiszka <[EMAIL PROTECTED]>:
> Gregory CLEMENT wrote:
> > Here, they are the last latency we get on AT91SAM9261-EK. As just now
> > I haven't the board at home, I send the last result we stored. The
> > prority of dbgu should be set to 6 instead of 7, but I can't assure
> > it, for Xenomai.
>
> Hmm, hardware interrupt priorities must not impact the worst-case
> latency if I-pipe acks and mask them appropriately (the worst case is
> when multiple interrupts happen in a row, not at the same time). But
> this statement is not based on knowledge about potential pitfalls of
> this arch. Are there specialities that require this tweaking?

Indeed there was little impact on Xenomai, but a big impact in RTAI. I
believe that in RTAI (or at least in our RTAI port), there is longer
critical section than in Xenomai.  We observe big latency when
calibrator was writing a lot of "\r" on serial line, that was causing
a lot of interrupts. I think that during a critical section (IT
disabled), we get an timer interrupt and a serial interrupt. As serial
interrupt has bigger priority it is treated first and as during an
interrupt serial driver can send or receive 256 character, it can add
a big delay.



>
> > first Xenomai:
> >
> > #insmod 
> > /lib/modules/2.6.20.13/kernel/drivers/xenomai/testing/xeno_timerbench.ko
> > #cd /usr/xenomai/bin/
>
> Which versions were you using for both tests? Do you still have the
> involved .configs?

Both version are 2.6.20.13
I join the config files.

>
> > #./latency -t 2 -p 150 -h -H 500
> ...
> > ---|||||-
> > RTS|   3.480|  11.779|  99.163|   0|14:23:01/14:23:01
> >
> > It was run under calibrator load during more than 14 hours.
> >
> > Now RTAI:
> >
> > Oneshot timer with 500µs period,  LATENCY =6000ns and SETUPTIME 1500
> >  duration : 17h
> >
> > 1970/01/1 22:34:51
> > RTH|lat min|ovl min|lat avg|lat max|ovl max|   overruns
> > RTD|   3221|   2577|   4997|  26095|  53801|  0
> > RTD|   3221|   2577|   5163|  25451|  53801|  0
> > RTD|   3221|   2577|   5159|  25128|  53801|  0
> > RTD|   3221|   2577|   4799|  23518|  53801|  0
> > RTD|   3221|   2577|   4828|  25128|  53801|  0
> > RTD|   3221|   2577|   5089|  23518|  53801|  0
> > RTD|   3221|   2577|   4580|  23840|  53801|  0
> > RTD|   3221|   2577|   4924|  25128|  53801|  0
> > RTD|   3221|   2577|   4740|  24806|  53801|  0
> > RTD|   3221|   2577|   4251|  25128|  53801|  0
>
> Again, what would simplify the discussion enormously is a function
> back-trace of the measured maximum latencies, just like "latency -f"
> generates. The numbers will become worse, for sure, but we would gain a
> very good overview about what is executed and what delayed which kernel.
> If you see a chance to perform such a test and you need some hints on
> the tracer setup (or did you use it before?), please let us know!

OK for try it, at least for Xenomai as the function exists, but I
can't do it tonight and not this week in fact.

> Jan
>
> --
> Siemens AG, Corporate Technology, CT SE 2
> Corporate Competence Center Embedded Linux
>


--
Gregory CLEMENT
Adeneo
Adetel Group
2, chemin du Ruisseau
69134 ECULLY - FRANCE
France
Tél. : +33 (0)4 72 18 08 40 - Fax : +33 (0)4 72 18 08 41

www.adetelgroup.com



-- 
Gregory CLEMENT
Adeneo
Adetel Group
2, chemin du Ruisseau
69134 ECULLY - FRANCE
France
Tél. : +33 (0)4 72 18 08 40 - Fax : +33 (0)4 72 18 08 41

www.adetelgroup.com


config-RTAI
Description: Binary data


config-Xenomai
Description: Binary data
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

[Xenomai-core] RTAI and Xenomai latency in kernel mode on AT91SAM9261-EK

2007-10-09 Thread Gregory CLEMENT 
 4
HSD|max|  62 - 63 |4
HSD|max|  69 - 70 |2
HSD|max|  70 - 71 |1
HSD|max|  71 - 72 |3
HSD|max|  72 - 73 |3
HSD|max|  73 - 74 |3
HSD|max|  74 - 75 |5
HSD|max|  75 - 76 |4
HSD|max|  76 - 77 |1
HSD|max|  77 - 78 |2
HSD|max|  78 - 79 |7
HSD|max|  80 - 81 |2
HSD|max|  81 - 82 |1
HSD|max|  82 - 83 |4
HSD|max|  83 - 84 |4
HSD|max|  84 - 85 |6
HSD|max|  85 - 86 |5
HSD|max|  86 - 87 |1
HSD|max|  87 - 88 |3
HSD|max|  88 - 89 |2
HSD|max|  89 - 90 |2
HSD|max|  90 - 91 |1
HSD|max|  92 - 93 |2
HSD|max|  93 - 94 |1
HSD|max|  94 - 95 |1
HSD|max|  95 - 96 |1
HSD|max|  96 - 97 |1
HSD|max|  99 -100 |1
HSH|--param|--samples-|--average--|---stddev--
HSS|min|   574|  6.686|  0.740
HSS|avg|   3826285| 11.213|  6.706
HSS|max|   574| 44.190| 15.169
---|||||-
RTS|   3.480|  11.779|  99.163|   0|14:23:01/14:23:01

It was run under calibrator load during more than 14 hours.

Now RTAI:

Oneshot timer with 500µs period,  LATENCY =6000ns and SETUPTIME 1500
 duration : 17h

1970/01/1 22:34:51
RTH|lat min|ovl min|lat avg|lat max|ovl max|   overruns
RTD|   3221|   2577|   4997|  26095|  53801|  0
RTD|   3221|   2577|   5163|  25451|  53801|  0
RTD|   3221|   2577|   5159|  25128|  53801|  0
RTD|   3221|   2577|   4799|  23518|  53801|  0
RTD|   3221|   2577|   4828|  25128|  53801|  0
RTD|   3221|   2577|   5089|  23518|  53801|  0
RTD|   3221|   2577|   4580|  23840|  53801|  0
RTD|   3221|   2577|   4924|  25128|  53801|  0
RTD|   3221|   2577|   4740|  24806|  53801|  0
RTD|   3221|   2577|   4251|  25128|  53801|  0

counts | latency
144 2
15830672 3
31593380 4
15873143 5
9913892 6
5682938 7
3193742 8
2095821 9
2173270 10
2856232 11
3693369 12
3430282 13
3359902 14
2784427 15
 809859 16
 322901 17
 224317 18
 208420 19
 411250 20
4054145 21
8386174 22
 514707 23
 261560 24
 223286 25
 187926 26
 171329 27
 233480 28
 116408 29
  47277 30
 812908 31
2751429 32
  38513 33
   5668 34
   2386 35
   2249 36
   1555 37
   1130 38
416 39
217 40
148 41
134 42
183 43
118 44
167 45
227 46
151 47
 95 48
 26 49
  8 50
  6 51
  7 52
  6 53



-- 
Gregory CLEMENT
Adeneo
Adetel Group
2, chemin du Ruisseau
69134 ECULLY - FRANCE
France
Tél. : +33 (0)4 72 18 08 40 - Fax : +33 (0)4 72 18 08 41

www.adetelgroup.com

___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Re: [Xenomai-core] RTOS porting on ARM

2007-10-09 Thread Gregory CLEMENT 
2007/10/9, Jan Kiszka <[EMAIL PROTECTED]>:
> Gregory CLEMENT wrote:
> > 2007/10/9, Jan Kiszka <[EMAIL PROTECTED]>:
> >> Gilles Chanteperdrix wrote:
> >>> gclement00 at gmail.com (Gregory CLEMENT) wrote:
> >>>  >
> >>>  > For RTAI we have now a working systeme with have better max latency
> >>>  > than Xenomai ( 50us instead of around 100us for Xenomai). I plan to
> >>>  > update the patches on our site with this new version and communicate
> >>>  > on it on RTAI list as soon as I have some free time.
> >>>
> >>> A good place for discussing about these figures would have been Xenomai
> >>> mailing list, a place where we could have answered you immediately. Are
> >>> you sure you are not comparing Xenomai user-space scheduling latency
> >>> with RTAI kernel-space scheduling latency ?
> >> Me too asked Gregory for some discussion on this long ago but received
> >> no response.
> >>
> >> Anyway, the critical thing beyond latencies remains *maintenance*. If
> >> someone decides to apply I-pipe on RTAI *and* doesn't forget to
> >> contribute to the mandatory bits of the Adeos project, work actively
> >> within that community (test new versions and report results, track down
> >> bugs, port to new kernels releases, etc.), anyone would benefit in the
> >> end. BTW, that would surely stimulate discussions about differing
> >> numbers on both sides as well.
> >
> > And you think we didn't contribute to adeos projects, test new version
> > and report result???
> > Because it is exactly what we have done.
>
> You did this for the startup of this port, and it is highly appreciated.
> But such things require lasting effort. Probably I'm just so sceptical
> because there have been many people before posting patches once and then
> never again. Just look at RTAI's ARM history of the last, mmh, 4 years.
> I'm always happy being proved wrong regarding such scepticisms of mine!

There is no more post on adeos mailing list just because we didn't
change it, since our last post.
As I mentioned earlier we just set dbgu priority level at a different
level, it is not a big change, but I will post the patch for it.

> > Our result on RTAI are pretty recent, and the lack of discussion on it
> > is only a lack of time and not a lack of wiling.
>
> Then I'm looking forward to have this now, e.g. backed up with tracer
> outputs of both variants.

As I mentionned, that for now, I am deep under load ? Because I am,
and so I will do my best but time is not extensible unforutnately.

>
> Jan
>
> --
> Siemens AG, Corporate Technology, CT SE 2
> Corporate Competence Center Embedded Linux
>


-- 
Gregory CLEMENT
Adeneo
Adetel Group
2, chemin du Ruisseau
69134 ECULLY - FRANCE
France
Tél. : +33 (0)4 72 18 08 40 - Fax : +33 (0)4 72 18 08 41

www.adetelgroup.com

___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Re: [Xenomai-core] RTOS porting on ARM

2007-10-09 Thread Gregory CLEMENT 
2007/10/9, Gilles Chanteperdrix <[EMAIL PROTECTED]>:
> On 10/9/07, Gregory CLEMENT <[EMAIL PROTECTED]> wrote:
> > 2007/10/9, Gilles Chanteperdrix <[EMAIL PROTECTED]>:
> > > Gregory CLEMENT wrote:
> > >  > 2007/10/8, Gilles Chanteperdrix <[EMAIL PROTECTED]>:
> > >  > > gclement00 at gmail.com (Gregory CLEMENT) wrote:
> > >  > >  > 2007/9/11, Bill Gatliff <[EMAIL PROTECTED]>:
> > >  > >  > > Richard Genoud wrote:
> > >  > >  > > >>   For an industrial control application, i need to port an 
> > > RTOS pn ARM9 specifically, cirrus logic based ARM. Can anyone suggest me 
> > > the chances of porting RT Linux on this ARM core. if not any other RTOS 
> > > please.
> > >  > >  > > >>
> > >  > >  > > >
> > >  > >  > > > Hi !
> > >  > >  > > >
> > >  > >  > > > we've started to port xenomai and RTAI to arm9 (AT91RM9200 & 
> > > AT91SAM926x)
> > >  > >  > > >
> > >  > >  > > > you can download the patches here :
> > >  > >  > > > 
> > > http://www.adeneo.adetelgroup.com/srt/adeneoen/flb/show?location.id:=1452
> > >  > >  > > >
> > >  > >  > > > Richard.
> > >  > >  > > >
> > >  > >  > >
> > >  > >  > > Xenomai already supports the AT91RM9200.
> > >  > >  >
> > >  > >  > Indeed and now Xenomai supports also AT91SAM9260,  AT91SAM9261 and
> > >  > >  > AT91SAM9263 as our patches are now in adeos.
> > >  > >
> > >  > > Hi,
> > >  > >
> > >  > > I have found this mail by chance with Google, and could not leave it
> > >  > > unanswered.
> > >  > >
> > >  > > First, let me clarify the situation of Xenomai ARM port. It is a
> > >  > > collective work which was started more that two years ago,
> > >  >
> > >  > I never said anything else.
> > >
> > > Read the quoted text again: "we've started to port xenomai and RTAI to 
> > > arm9 (AT91RM9200 & AT91SAM926x)"
> >
> > OK, but it is not me who said this. The person who said this wasn't
> > really aware of our work, and misunderstood what we have done.
> >
> > >
> > >  > >  > For RTAI we have now a working systeme with have better max 
> > > latency
> > >  > >  > than Xenomai ( 50us instead of around 100us for Xenomai). I plan 
> > > to
> > >  > >  > update the patches on our site with this new version and 
> > > communicate
> > >  > >  > on it on RTAI list as soon as I have some free time.
> > >  > >
> > >  > > A good place for discussing about these figures would have been 
> > > Xenomai
> > >  > > mailing list, a place where we could have answered you immediately. 
> > > Are
> > >  > > you sure you are not comparing Xenomai user-space scheduling latency
> > >  > > with RTAI kernel-space scheduling latency ?
> > >  >
> > >  > I thought a best place was RTAI list, as we ever communicated on
> > >  > Xenomai latency on xenomai and adeos list. For example in
> > >  > https://mail.gna.org/public/adeos-main/2007-05/msg2.html .
> > >  > Unfortunately, I have now a lot to do, and a very few extra time for
> > >  > it :o/ I hope will be able to work on it soon.
> > >  >
> > >  >
> > >  > Sorry if it this thread hurt you, it wasn't our intention to claim a
> > >  > work we didn't have done. And I hope we will be able to work again on
> > >  > the subject as there is still room for improvement.
> > >
> > > The thing I do not appreciate is the claim about latencies. Either you
> > > are right, and we should find what the problem is, or you are comparing
> > > apples and oranges, and your statistics are totally irrelevant.
> >
> > But you have the test latency we ran. We compared latency in the best
> > mode of both RTAI and Xenomai, ie in kernel mode.
>
> If I read the statistics you posted on the Adeos mailing list, here:
> https://mail.gna.org/public/adeos-main/2007-06/msg00023.html
>
> You had latencies smaller than 100us already in user-space. So, the
> fact that you get higher latencies in kernel-space i

Re: [Xenomai-core] Atmel AT91SAM support in Xenomai

2007-06-21 Thread Gregory CLEMENT 
2007/6/21, Claudio Scordino <[EMAIL PROTECTED]>:
> Dear Gregory,
>
> we haven't started working on Xenomai on the AT91SAM platform, yet.
>
> Actually, we don't even know if we will...
>
> Can you tell me what is the current status of the AT91SAM support in Xenomai ?
> I remember that you already sent me a preliminary patch some weeks ago...

Our patch for AT91SAM926x support are already merged in the Xenomai
arm git tree. Gilles was waiting for some feedback on his new patch
for making a release of it.


> Did you make any change ? Is the current support working ? If so, when the 
> patch
> will be merged with the standard mainstream of Xenomai ?

The support is working we test it both on AT91SAM9260-EK and
AT91SAM9261-EK board, and we already sent the real time performance on
these list two weekd ago.


-- 
Gregory CLEMENT
Adeneo
2, chemin du Ruisseau - BP21
69136 Ecully Cedex
France
Tel : +33-4 72 18 08 40

___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Re: [Xenomai-core] [Adeos-main] AT91 patch duplicated code ...

2007-06-10 Thread Gregory CLEMENT 
2007/6/9, Gilles Chanteperdrix <[EMAIL PROTECTED]>:
> Gregory CLEMENT wrote:
>  > 2007/6/8, Gilles Chanteperdrix <[EMAIL PROTECTED]>:
>  > > BOUIN Alexandre wrote:
>  > >  >
>  > >  > > When we released our last version of 
> adeos-ipipe-2.6.19-arm-AT91.patch, we suggested to merge code for at91rm9200 
> and at91sam926x.
>  > >  > > These 2 code are split but quite similar, so we think it could be a 
> good idea. Are you OK for removing duplicated code ?
>  > >
>  > > If I have to choose between duplicating some Linux code in I-pipe code
>  > > and have some duplication in the I-pipe patch, I choose duplication in
>  > > the I-pipe patch. If you duplicate Linux code, you will have to avoid
>  > > forgetting to update this duplicate code when Linux code evolves.
>  > >
>  >
>  > Well the first mail wasn't very clear. I am going to explain what we
>  > have in mind.
>  >
>  > In Linux code for AT91 timer there are two files: at91sam926x_time.c
>  > and at91rm9200_time.c because AT91RM9200 and AT91SAM926x have
>  > different system timer: AT91RM9200 use AT91_ST peripheral and
>  > AT91SAM926x use AT91_PIT peripheral.
>
> I was somehow thinking that there was something else in at91xx_time.c
> than what is enclosed in #ifdef CONFIG_IPIPE. I was wrong.
>
> Now, I have another question: is there no way to use the AT91_PIT
> peripheral in one shot mode ? What is the resolution of this PIT ?
>
> In any case, please send a patch, this will make a real base for
> discussion.

Here it is!
As I have no AT91 board at home, I just test that it compil without
error. But this patch is a good start for discussion.

-- 
Gregory CLEMENT
Adeneo
2, chemin du Ruisseau - BP21
69136 Ecully Cedex
France
Tel : +33-4 72 18 08 40


>From a5e44b874bbdb444115be753debbcc8f36edd7c5 Mon Sep 17 00:00:00 2001
From: Gregory CLEMENT <[EMAIL PROTECTED]>
Date: Sun, 10 Jun 2007 13:05:26 +0200
Subject: [PATCH] Merge AT91RM200 and AT91SAM926x timer ipipe in only one file

---
 arch/arm/mach-at91rm9200/Makefile   |   16 +-
 arch/arm/mach-at91rm9200/at91ipipe_time.c   |  335 +++
 arch/arm/mach-at91rm9200/at91rm9200_time.c  |  295 +---
 arch/arm/mach-at91rm9200/at91sam926x_time.c |  312 -
 4 files changed, 349 insertions(+), 609 deletions(-)
 create mode 100644 arch/arm/mach-at91rm9200/at91ipipe_time.c

diff --git a/arch/arm/mach-at91rm9200/Makefile
b/arch/arm/mach-at91rm9200/Makefile
index cf77700..c3d00dc 100644
--- a/arch/arm/mach-at91rm9200/Makefile
+++ b/arch/arm/mach-at91rm9200/Makefile
@@ -10,9 +10,19 @@ obj- :=
 obj-$(CONFIG_PM)   += pm.o

 # CPU-specific support
-obj-$(CONFIG_ARCH_AT91RM9200)  += at91rm9200.o at91rm9200_time.o
at91rm9200_devices.o
-obj-$(CONFIG_ARCH_AT91SAM9260) += at91sam9260.o at91sam926x_time.o
at91sam9260_devices.o
-obj-$(CONFIG_ARCH_AT91SAM9261) += at91sam9261.o at91sam926x_time.o
at91sam9261_devices.o
+obj-$(CONFIG_ARCH_AT91RM9200)   += at91rm9200.o at91rm9200_devices.o
+obj-$(CONFIG_ARCH_AT91SAM9260)  += at91sam9260.o at91sam9260_devices.o
+obj-$(CONFIG_ARCH_AT91SAM9261)  += at91sam9261.o at91sam9261_devices.o
+
+ifeq ($(CONFIG_IPIPE),y)
+obj-$(CONFIG_ARCH_AT91RM9200)   += at91ipipe_time.o
+obj-$(CONFIG_ARCH_AT91SAM9260)  += at91ipipe_time.o
+obj-$(CONFIG_ARCH_AT91SAM9261)  += at91ipipe_time.o
+else
+obj-$(CONFIG_ARCH_AT91RM9200)   += at91rm9200_time.o
+obj-$(CONFIG_ARCH_AT91SAM9260)  += at91sam926x_time.o
+obj-$(CONFIG_ARCH_AT91SAM9261)  += at91sam926x_time.o
+endif

 # AT91RM9200 board-specific support
 obj-$(CONFIG_MACH_ONEARM)  += board-1arm.o
diff --git a/arch/arm/mach-at91rm9200/at91ipipe_time.c
b/arch/arm/mach-at91rm9200/at91ipipe_time.c
new file mode 100644
index 000..b236611
--- /dev/null
+++ b/arch/arm/mach-at91rm9200/at91ipipe_time.c
@@ -0,0 +1,335 @@
+/*
+ * linux/arch/arm/mach-at91rm9200/at91ipipe_time.c
+ *
+ * Copyright (C) 2007 Gregory CLEMENT, Adeneo
+ * based on at91rm9200_time.c patched by Gilles Chanteperdrix
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include 
+
+static unsigned long last_crtr;
+
+#include 
+#include 
+#include 
+#include 
+#include "clock.h"
+
+#if defined(CONFIG_ARCH_AT91RM9200)
+#include 
+#define AT91_ID_TC0 AT91RM9200_ID_TC0
+#define AT91_ID_TC1 AT91RM9200_ID_TC1
+#define AT91_ID_TC2 AT91RM9200_ID_TC2
+#elif defined(CONFIG_ARCH_AT91SAM9260)
+#include 
+#define AT91_ID_TC0 AT91SAM9260_ID_TC0
+#define AT91_ID_TC1 AT91SAM9260_ID_TC1
+#define AT91_ID_TC2 AT91SAM9260_ID_TC2
+#elif defined(C

Re: [Xenomai-core] [Adeos-main] periodic mode in adeos-ipipe for arm at91 ...

2007-06-09 Thread Gregory CLEMENT 
2007/6/8, Gilles Chanteperdrix <[EMAIL PROTECTED]>:
> BOUIN Alexandre wrote:
>  >  We (Adeneo) are working on a ARM AT91 RTAI. We encountered 
> some difficulties such tsc one : in periodic mode, we reload our timer 
> automatically in order to avoid reprogramming it. TC timer increments a 16 
> byte register, which is not enough for a tsc (64 bytes). tsc need to be 
> emulated on ARM.
>  >  With oneshot mode, tsc is updating the 4 least significant 
> bytes and then increments other bytes each time counter go back to zero value.
>  >
>  >  With our periodic mode, timer reloads himself so we need to 
> change tsc emulation by incrementing tsc like this : tsc += period.
>  >  We made some evolutions on ipipe which will be applied to a 
> hal patch.
>
> I intend to rework I-pipe tsc emulation for arms with a free-running
> counter. In order to reduce the tsc read operations:
> - it should use the (uninterruptible) ldm instruction to load the 64
>   bits counter without masking interrupts;
> - the 64 bits counter should not be updated at each read, but only from
>   time to time, the best place to do this is Linux timer interrupt.

If 64 bits counter is not updated at each read, we still need to load
it, read the current value of free-running counter, compare it to its
last value when 64 bits counter was updated. If we don't do this we
loose granularity.
So the gain is only on not writing the 64  bits counter, or maybe I
missed something ?

-- 
Gregory CLEMENT
Adeneo
2, chemin du Ruisseau - BP21
69136 Ecully Cedex
France
Tel : +33-4 72 18 08 40

___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Re: [Xenomai-core] [Adeos-main] periodic mode in adeos-ipipe for arm at91 ...

2007-06-09 Thread Gregory CLEMENT 
2007/6/9, Gilles Chanteperdrix <[EMAIL PROTECTED]>:
> Gilles Chanteperdrix wrote:
>  > BOUIN Alexandre wrote:
>  >  >   We (Adeneo) are working on a ARM AT91 RTAI. We encountered 
> some difficulties such tsc one : in periodic mode, we reload our timer 
> automatically in order to avoid reprogramming it. TC timer increments a 16 
> byte register, which is not enough for a tsc (64 bytes). tsc need to be 
> emulated on ARM.
>  >  >   With oneshot mode, tsc is updating the 4 least significant 
> bytes and then increments other bytes each time counter go back to zero value.
>  >  >
>  >  >   With our periodic mode, timer reloads himself so we need to 
> change tsc emulation by incrementing tsc like this : tsc += period.
>  >  >   We made some evolutions on ipipe which will be applied to a 
> hal patch.
>  >
>  > I intend to rework I-pipe tsc emulation for arms with a free-running
>  > counter. In order to reduce the tsc read operations:
>  > - it should use the (uninterruptible) ldm instruction to load the 64
>  >   bits counter without masking interrupts;
>  > - the 64 bits counter should not be updated at each read, but only from
>  >   time to time, the best place to do this is Linux timer interrupt.
>
> I never did the calculation before, but the TC free-running counter
> wraps every 40 milliseconds, so Linux timer interrupt is not often

How do you get this 40 ms ?
For me TC free-running counter wraps every (2^16)/(MCK/32)
For AT91RM9200-EK  MCK=59904000 so we get 35ms
For AT91SMA926x-EK MCK=99328000 so we get 21ms
I am wrong?

> enough to update the 64 bits counter. The only safe place to update the
> 64 bits counter seems to be __ipipe_mach_acktimer.

As Linux timer period is 10ms why do you think is not often enough ?

For AT91SAM926x what do you think of using PIT for emulating tsc,
(with PIT we can have a 32 bit counter) ?


-- 
Gregory CLEMENT
Adeneo
2, chemin du Ruisseau - BP21
69136 Ecully Cedex
France
Tel : +33-4 72 18 08 40

___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Re: [Xenomai-core] [Adeos-main] AT91 patch duplicated code ...

2007-06-09 Thread Gregory CLEMENT 
2007/6/9, Gilles Chanteperdrix <[EMAIL PROTECTED]>:
> Gregory CLEMENT wrote:
>  > 2007/6/8, Gilles Chanteperdrix <[EMAIL PROTECTED]>:
>  > > BOUIN Alexandre wrote:
>  > >  >
>  > >  > > When we released our last version of 
> adeos-ipipe-2.6.19-arm-AT91.patch, we suggested to merge code for at91rm9200 
> and at91sam926x.
>  > >  > > These 2 code are split but quite similar, so we think it could be a 
> good idea. Are you OK for removing duplicated code ?
>  > >
>  > > If I have to choose between duplicating some Linux code in I-pipe code
>  > > and have some duplication in the I-pipe patch, I choose duplication in
>  > > the I-pipe patch. If you duplicate Linux code, you will have to avoid
>  > > forgetting to update this duplicate code when Linux code evolves.
>  > >
>  >
>  > Well the first mail wasn't very clear. I am going to explain what we
>  > have in mind.
>  >
>  > In Linux code for AT91 timer there are two files: at91sam926x_time.c
>  > and at91rm9200_time.c because AT91RM9200 and AT91SAM926x have
>  > different system timer: AT91RM9200 use AT91_ST peripheral and
>  > AT91SAM926x use AT91_PIT peripheral.
>
> I was somehow thinking that there was something else in at91xx_time.c
> than what is enclosed in #ifdef CONFIG_IPIPE. I was wrong.
>
> Now, I have another question: is there no way to use the AT91_PIT
> peripheral in one shot mode ?

PIT is for Peridodic Interval Timer, and after reading the datasheet
it seems that this peripheral is not made for one shot timer.
All we can do is force PIT to stop after a reset but in all case when
PIT reach the programmable overflow it reset. We can't use it a free
running counter.

>  What is the resolution of this PIT ?

The resolution of PIT is MCK/16

> In any case, please send a patch, this will make a real base for
> discussion.

Ok I will try to do that.

-- 
Gregory CLEMENT
Adeneo
2, chemin du Ruisseau - BP21
69136 Ecully Cedex
France
Tel : +33-4 72 18 08 40

___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Re: [Xenomai-core] [Adeos-main] AT91 patch duplicated code ...

2007-06-08 Thread Gregory CLEMENT 
2007/6/8, Gilles Chanteperdrix <[EMAIL PROTECTED]>:
> BOUIN Alexandre wrote:
>  >
>  > > When we released our last version of adeos-ipipe-2.6.19-arm-AT91.patch, 
> we suggested to merge code for at91rm9200 and at91sam926x.
>  > > These 2 code are split but quite similar, so we think it could be a good 
> idea. Are you OK for removing duplicated code ?
>
> If I have to choose between duplicating some Linux code in I-pipe code
> and have some duplication in the I-pipe patch, I choose duplication in
> the I-pipe patch. If you duplicate Linux code, you will have to avoid
> forgetting to update this duplicate code when Linux code evolves.
>

Well the first mail wasn't very clear. I am going to explain what we
have in mind.

In Linux code for AT91 timer there are two files: at91sam926x_time.c
and at91rm9200_time.c because AT91RM9200 and AT91SAM926x have
different system timer: AT91RM9200 use AT91_ST peripheral and
AT91SAM926x use AT91_PIT peripheral.
But with i-pipe we use TC (timer counter) in both case, and code is
the same (the only difference are in the name of internal function).
When CONFIG_IPIPE is defined, original Linux code is no more used and
it is new i-pipe code which is used.
I suggest to add a new file in i-pipe patch, let's call it
"at91ipipe_time.c". In this file we will find the common ipipe code.
This file will be compiled in place of at91sam926x_time.c and
at91rm9200_time.c. For doing this we just have to change Makefile with
something like this:

# CPU-specific support
obj-$(CONFIG_ARCH_AT91RM9200)   += at91rm9200.o at91rm9200_devices.o
obj-$(CONFIG_ARCH_AT91SAM9260)  += at91sam9260.o at91sam9260_devices.o
obj-$(CONFIG_ARCH_AT91SAM9261)  += at91sam9261.o at91sam9261_devices.o

ifeq ($(CONFIG_IPIPE),y)
obj-$(CONFIG_ARCH_AT91RM9200)   += at91ipipe_time.o
obj-$(CONFIG_ARCH_AT91SAM9260)  += at91ipipe_time.o
obj-$(CONFIG_ARCH_AT91SAM9261)  += at91ipipe_time.o at91sam9261_devices.o
else
obj-$(CONFIG_ARCH_AT91RM9200)   += at91rm9200_time.o
obj-$(CONFIG_ARCH_AT91SAM9260)  += at91sam926x_time.o
obj-$(CONFIG_ARCH_AT91SAM9261)  += at91sam926x_time.o
endif


-- 
Gregory CLEMENT
Adeneo
2, chemin du Ruisseau - BP21
69136 Ecully Cedex
France
Tel : +33-4 72 18 08 40

___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Re: [Xenomai-core] getting negative values in interrupt latency in xenomai

2007-05-23 Thread Gregory CLEMENT 
2007/5/23, manoj kumar <[EMAIL PROTECTED]>:
> Hi,
>
> i am runnigthe latency test on i386 platform with 1 GB ram and intel pentium
> 4 runnig at 2.66GHz . i am getting some negative values as lat best and avg.
> The results are as below
>
>
> User space interrupt latency output
>
> == Sampling period: 1 us
>
> == Test mode: periodic user-mode task
>
> == All results in microseconds
>
> warming up...
>
> RTT|  00:00:01   (periodic user-mode task, 1 us period, priority 99)
>
> RTH|-lat min|-lat avg|-lat max|-overrun|lat best|---lat
> worst
>
> RTD|  -1.775|   -1.374|   0.953|   0|  -1.775|
> 0.953
>
> RTD|  -1.790|  -1.355|   3.142|   0|  -1.790|
> 3.142
>
> RTD|  -1.812|   -1.266|   4.158|   0|  -1.812|
> 4.158
>
> RTD|  -1.797|   -1.272|   6.602|   0|  -1.812|
> 6.602
>
> RTD|  -1.764|   -1.365|   0.575|   0|  -1.812|
> 6.602
>
> RTD|  -1.895|   -1.370|   0.859|   0|  -1.895|
> 6.602
>
> RTD|  -1.857|   -1.421|   0.908|   0|  -1.895|
> 6.602
>
> RTD|  -1.782|   -1.293|   5.845|   0|  -1.895|
> 6.602
>
> RTD|  -1.929|   -1.362|   1.204|   0|  -1.929|
> 6.602
>
> RTD|  -1.775|   -1.359|   0.844|   0|  -1.929|
> 6.602
>
> RTD|  -1.794|   -1.346|   0.724|   0|  -1.929|
> 6.602
>
> RTD|  -1.756|  -1.318|   1.021|   0|  -1.929|
> 6.602
>
> RTD|  -1.775|   -1.269|   8.064|   0|  -1.929|
> 8.064
>
> RTD|  -1.805|   -1.395|   0.893|   0|  -1.929|
> 8.064
>
> RTD|  -1.779|1.530| 281.147|   0|  -1.929|
> 281.147
>
> RTD|  -1.959|   -1.362|   1.118|   0|  -1.959|
> 281.147
> Could any figure out why these negative values are coming and reason behind
> that and how i can avoid these.
>
> is it a configuration issuse.

You have to calibrate xenomai by feeding with your average latency
/proc/xenomai/latency



>
> Thanks & regards
> Manoj


-- 
Gregory CLEMENT
Adeneo
2, chemin du Ruisseau - BP21
69136 Ecully Cedex
France
Tel : +33-4 72 18 08 40

___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Re: [Xenomai-core] Atmel AT91SAM support ?

2007-04-20 Thread Gregory CLEMENT 
2007/4/20, Claudio Scordino <[EMAIL PROTECTED]>:
> Hi,
Hi Claudio,

>
>I saw that Xenomai supports the Atmel AT91RM9200 processor. Does it support
> the AT91SAM9260 as well ?

We are also working on it, and we have already sent a patch for it (in
fact for AT91SAM9261 but there as the same for real time).
There were some mistakes pointed by Gilles Chanteperdrix, but I think
there will be a new patch sooner, ever made by Gille or by us.


-- 
Gregory CLEMENT
Adeneo
2, chemin du Ruisseau - BP21
69136 Ecully Cedex
France
Tel : +33-4 72 18 08 40

___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core