[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 gregory.clem...@free-electrons.com
Date: Sat, 29 Oct 2011 19:16:57 +0200
Subject: [PATCH 1/1] Adeos / Xenomai port for AT91SAM9M10G45-EK


Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
---
 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 - AT91SAM9G45_SRAM_SIZE,
 		.pfn

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] Adeos patch to make RTAI works on AT91SAM926x

2007-10-10 Thread Gregory CLEMENT 
 ipipe_control_irq(unsigned irq, unsi

 int fastcall __ipipe_dispatch_event (unsigned event, void *data)
 {
+   extern void *ipipe_irq_handler;
+   void *handler;
+   if (ipipe_irq_handler != __ipipe_handle_irq  (handler =
ipipe_root_domain-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

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 is highly
 suspicious.

Where do you see it is in user space ? The latency are colected in
kernel module, it is just display wich is in user space.
Then the 100us I mentionned are under calibrator load, which is the
application which give the worse resulats. On the result yout point
the max lantency is 200us.
We reached 100us by set dbgu priority to 6, and maintain timer
priority to 7. Indeed serial output on dbu give bad latency as it its
peripheral ID is 0, so with the same level of priority in AIC, its
interrupt are treated first. We change this in adeos fot both RTAI and
Xenomai.
Maybe this change can be done in adeos main tree.


  In RTAI path from it to RTAI seems more direct than in Xenomai even in
  kernel mode. I say this by reading code, it is not just a guess. So it
  is not surprising to me that there is better latency in RTAI. I am not
  sure there is a problem to find, the software architecture are
  different.

 Latencies are supposed to be due to hardware effects, the software
 path should have little effect. If software has such an high effect
 then we have a problem. But as I said, a 100 us latency in
 kernel-space is suspicious if you get latencies smaller than 100us in
 user-space.

  You can test RTAI on AT91RM9200 (as AT91RM9200 is merly equal to
  AT91SAM926x) the patches are on RTAI contrib repository:
  http://www.rtai.org/RTAICONTRIB/

 You are the one who publishes comparisons, so you are the one who
 should run the tests rigorously.

I thinks our tests are rigorous, but I am open to disuss

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

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

2007-10-09 Thread Gregory CLEMENT 
|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

[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

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 linux/init.h
+#include linux/interrupt.h
+#include linux/irq.h
+#include linux/kernel.h
+#include linux/sched.h
+#include linux/time.h
+
+#include asm/hardware.h
+#include asm/io.h
+#include asm/mach/time.h
+
+#include asm/arch/at91_pit.h
+
+static unsigned long last_crtr;
+
+#include linux/clk.h
+#include linux/console.h
+#include linux/module.h
+#include asm/arch/at91_tc.h
+#include clock.h
+
+#if defined(CONFIG_ARCH_AT91RM9200)
+#include asm/arch/at91rm9200.h
+#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 asm/arch/at91sam9260.h
+#define AT91_ID_TC0 AT91SAM9260_ID_TC0
+#define AT91_ID_TC1 AT91SAM9260_ID_TC1
+#define AT91_ID_TC2 AT91SAM9260_ID_TC2
+#elif defined(CONFIG_ARCH_AT91SAM9261)
+#include asm/arch/at91sam9261.h
+#define

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] 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] 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