RE: [Xenomai-core] Xenomai on Freescale i.MX21 (ARM926J)
Hi Philippe, Any chance to see our work integrated within an official distribution? Are you still reviewing the code? Thanks for your feedback Daniel -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de ROSSIER Daniel Envoyé : mardi, 25. avril 2006 15:17 À : Philippe Gerum Cc : xenomai-core@gna.org Objet : RE: [Xenomai-core] Xenomai on Freescale i.MX21 (ARM926J) -Message d'origine- De : Philippe Gerum [mailto:[EMAIL PROTECTED] Envoyé : jeudi, 20. avril 2006 15:43 À : ROSSIER Daniel Cc : xenomai-core@gna.org Objet : Re: [Xenomai-core] Xenomai on Freescale i.MX21 (ARM926J) ROSSIER Daniel wrote: Dear all, We finally succeeded in the port of Xenomai on our Freescale i.MX21 board (ARM-926J); (The board used is the CSB535FS issued from Cogent with the BSP from Microcross) To have further technical references, please see there: http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=i.MX_LITEKI TparentCode=i.MX21nodeId=0162468rH31143ZrDR So, you will find two patches: the first one (patch-linux- 2.6.14.imx21_1.0.0) is used to patch the Linux 2.6.14 for supporting the board. Then, the second one (adeos-ipipe-2.6.14-arm-imx21-0.1.00.patch) can be used against the imx21-enabled kernel for Xenomai, simply using the prepare-kernel.sh script. The patch was originally inspired from the Integrator/ARM11 patch; thanks to its author :-) We will publish soon some results regarding the different latencies, but so far we measured about 2us between the IRQ and the timer reprogramming (at the ipipe level). The problem now is the jitter which is pretty high: about 1-2us, with some occasional peaks up to 5us. Having quite a few experience with this kind of board, we don't know if it comes from the code itself, or purely from the hardware. Any idea/suggestions would be welcome. For periodic tasks around 20us, everything works perfecly. Those results are pretty impressive actually. Assuming that you compare those figures with those obtained from traditional standalone RTOS e.g. VxWorks on the same board, the critical difference with Xenomai is that Linux is competing for the hw resources, and for instance, happily trashes the cache under Xenomai's feet when scheduling its own tasks during Xeno's idle time. Additionally, Adeos adds a small overhead due to the interrupt virtualization, in exchange of real-time predictability for their delivery. Therefore, in this respect, 5 us does not look that bad already. Are 20 us a measure of the worst-case interrupt latency (i.e. running latency -t2), or scheduling latency in user-space (i.e. running latency -t0)? No, I think we can go lower; the measure we actually got between the IRQ and the timer reprogramming is about 2 us with some jitters up to 5 us; we could normally guarantee not to exceed 5 us between the IRQ and timer reprogramming. Now, considering the ISR itself, we could get some time under 10us provided that the ISR remains short. So far, we measured the reaction time with the oscillo; we are now about to check the latencies with the latency utility from Xenomai. I don't know to what extent this (1 or 2) patch(es) can be integrated in the official distribution; but of course we are willing to make any adaptations to fulfill the requirements for that. For the technical part, I guess that anyone interested in the ARM support for Adeos/Xenomai will review this code; I'll be one of these people, for sure. The usefulness of such contribution looks obvious to me. For the non-technical part, a pre-requisite for adding code to the Adeos or Xenomai codebases is to properly identify it as coming from a legitimate source, so if you, as a submitter, can confirm that you may freely contribute it on behalf of the HEIG-VD (I guess?) or yourself, that's fine with us. Btw, at first glance, I did not find any additional GPL copyrights coming with your changes in the patches, it would be better to have them, so that we always know who contributed to what, as much as possible. Yes, it's ok. HEIG-VD is the University of Applied Sciences of Western Switzerland in Yverdon (http://www.heig-vd.ch) and I'm working at the REDS Institute (http://reds.eivd.ch, unfortunately in French only at the moment). We are granted to publish our work, at least all part which are not directly bound to some industrial projects (I'm trying to keep the stuff as open and public as possible ;-). It's a first step; I hope it will help some other ARM9 developers and look forward to reading some feedbacks. I profit to thank a lot the Xenomai team (Philippe, Jan, Gilles and the others) for their excellent work and support). Xenomai exists because people participate in the Sisyphean task of making it better, like you just did. In other words, welcome
Re: [Xenomai-core] Xenomai on Freescale i.MX21 (ARM926J)
ROSSIER Daniel wrote: Hi Philippe, Any chance to see our work integrated within an official distribution? Are you still reviewing the code? It's reviewed and mostly ok, except the poll mode boot parameter which is not there (i.e. adding a static compilation option is not the way to go). The main issue that remains is to merge it properly with the latest Adeos codebase (i.e. w/ pipeline head optimizations and wired IRQ support), and optionally, with the existing ARM port for the ARM1136, but since the i.MX21 support needs to be provided by an additional patch, the latter seems unlikely, unfortunately. Thanks for your feedback Daniel -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de ROSSIER Daniel Envoyé : mardi, 25. avril 2006 15:17 À : Philippe Gerum Cc : xenomai-core@gna.org Objet : RE: [Xenomai-core] Xenomai on Freescale i.MX21 (ARM926J) -Message d'origine- De : Philippe Gerum [mailto:[EMAIL PROTECTED] Envoyé : jeudi, 20. avril 2006 15:43 À : ROSSIER Daniel Cc : xenomai-core@gna.org Objet : Re: [Xenomai-core] Xenomai on Freescale i.MX21 (ARM926J) ROSSIER Daniel wrote: Dear all, We finally succeeded in the port of Xenomai on our Freescale i.MX21 board (ARM-926J); (The board used is the CSB535FS issued from Cogent with the BSP from Microcross) To have further technical references, please see there: http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=i.MX_LITEKI TparentCode=i.MX21nodeId=0162468rH31143ZrDR So, you will find two patches: the first one (patch-linux- 2.6.14.imx21_1.0.0) is used to patch the Linux 2.6.14 for supporting the board. Then, the second one (adeos-ipipe-2.6.14-arm-imx21-0.1.00.patch) can be used against the imx21-enabled kernel for Xenomai, simply using the prepare-kernel.sh script. The patch was originally inspired from the Integrator/ARM11 patch; thanks to its author :-) We will publish soon some results regarding the different latencies, but so far we measured about 2us between the IRQ and the timer reprogramming (at the ipipe level). The problem now is the jitter which is pretty high: about 1-2us, with some occasional peaks up to 5us. Having quite a few experience with this kind of board, we don't know if it comes from the code itself, or purely from the hardware. Any idea/suggestions would be welcome. For periodic tasks around 20us, everything works perfecly. Those results are pretty impressive actually. Assuming that you compare those figures with those obtained from traditional standalone RTOS e.g. VxWorks on the same board, the critical difference with Xenomai is that Linux is competing for the hw resources, and for instance, happily trashes the cache under Xenomai's feet when scheduling its own tasks during Xeno's idle time. Additionally, Adeos adds a small overhead due to the interrupt virtualization, in exchange of real-time predictability for their delivery. Therefore, in this respect, 5 us does not look that bad already. Are 20 us a measure of the worst-case interrupt latency (i.e. running latency -t2), or scheduling latency in user-space (i.e. running latency -t0)? No, I think we can go lower; the measure we actually got between the IRQ and the timer reprogramming is about 2 us with some jitters up to 5 us; we could normally guarantee not to exceed 5 us between the IRQ and timer reprogramming. Now, considering the ISR itself, we could get some time under 10us provided that the ISR remains short. So far, we measured the reaction time with the oscillo; we are now about to check the latencies with the latency utility from Xenomai. I don't know to what extent this (1 or 2) patch(es) can be integrated in the official distribution; but of course we are willing to make any adaptations to fulfill the requirements for that. For the technical part, I guess that anyone interested in the ARM support for Adeos/Xenomai will review this code; I'll be one of these people, for sure. The usefulness of such contribution looks obvious to me. For the non-technical part, a pre-requisite for adding code to the Adeos or Xenomai codebases is to properly identify it as coming from a legitimate source, so if you, as a submitter, can confirm that you may freely contribute it on behalf of the HEIG-VD (I guess?) or yourself, that's fine with us. Btw, at first glance, I did not find any additional GPL copyrights coming with your changes in the patches, it would be better to have them, so that we always know who contributed to what, as much as possible. Yes, it's ok. HEIG-VD is the University of Applied Sciences of Western Switzerland in Yverdon (http://www.heig-vd.ch) and I'm working at the REDS Institute (http://reds.eivd.ch, unfortunately in French only at the moment). We are granted to publish our work, at least all part which are not directly bound to some industrial projects (I'm trying to keep the stuff as open and public as possible ;-). It's
RE: [Xenomai-core] Xenomai on Freescale i.MX21 (ARM926J)
-Message d'origine- De : Philippe Gerum [mailto:[EMAIL PROTECTED] Envoyé : jeudi, 20. avril 2006 15:43 À : ROSSIER Daniel Cc : xenomai-core@gna.org Objet : Re: [Xenomai-core] Xenomai on Freescale i.MX21 (ARM926J) ROSSIER Daniel wrote: Dear all, We finally succeeded in the port of Xenomai on our Freescale i.MX21 board (ARM-926J); (The board used is the CSB535FS issued from Cogent with the BSP from Microcross) To have further technical references, please see there: http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=i.MX_LITEKI TparentCode=i.MX21nodeId=0162468rH31143ZrDR So, you will find two patches: the first one (patch-linux- 2.6.14.imx21_1.0.0) is used to patch the Linux 2.6.14 for supporting the board. Then, the second one (adeos-ipipe-2.6.14-arm-imx21-0.1.00.patch) can be used against the imx21-enabled kernel for Xenomai, simply using the prepare-kernel.sh script. The patch was originally inspired from the Integrator/ARM11 patch; thanks to its author :-) We will publish soon some results regarding the different latencies, but so far we measured about 2us between the IRQ and the timer reprogramming (at the ipipe level). The problem now is the jitter which is pretty high: about 1-2us, with some occasional peaks up to 5us. Having quite a few experience with this kind of board, we don't know if it comes from the code itself, or purely from the hardware. Any idea/suggestions would be welcome. For periodic tasks around 20us, everything works perfecly. Those results are pretty impressive actually. Assuming that you compare those figures with those obtained from traditional standalone RTOS e.g. VxWorks on the same board, the critical difference with Xenomai is that Linux is competing for the hw resources, and for instance, happily trashes the cache under Xenomai's feet when scheduling its own tasks during Xeno's idle time. Additionally, Adeos adds a small overhead due to the interrupt virtualization, in exchange of real-time predictability for their delivery. Therefore, in this respect, 5 us does not look that bad already. Are 20 us a measure of the worst-case interrupt latency (i.e. running latency -t2), or scheduling latency in user-space (i.e. running latency -t0)? No, I think we can go lower; the measure we actually got between the IRQ and the timer reprogramming is about 2 us with some jitters up to 5 us; we could normally guarantee not to exceed 5 us between the IRQ and timer reprogramming. Now, considering the ISR itself, we could get some time under 10us provided that the ISR remains short. So far, we measured the reaction time with the oscillo; we are now about to check the latencies with the latency utility from Xenomai. I don't know to what extent this (1 or 2) patch(es) can be integrated in the official distribution; but of course we are willing to make any adaptations to fulfill the requirements for that. For the technical part, I guess that anyone interested in the ARM support for Adeos/Xenomai will review this code; I'll be one of these people, for sure. The usefulness of such contribution looks obvious to me. For the non-technical part, a pre-requisite for adding code to the Adeos or Xenomai codebases is to properly identify it as coming from a legitimate source, so if you, as a submitter, can confirm that you may freely contribute it on behalf of the HEIG-VD (I guess?) or yourself, that's fine with us. Btw, at first glance, I did not find any additional GPL copyrights coming with your changes in the patches, it would be better to have them, so that we always know who contributed to what, as much as possible. Yes, it's ok. HEIG-VD is the University of Applied Sciences of Western Switzerland in Yverdon (http://www.heig-vd.ch) and I'm working at the REDS Institute (http://reds.eivd.ch, unfortunately in French only at the moment). We are granted to publish our work, at least all part which are not directly bound to some industrial projects (I'm trying to keep the stuff as open and public as possible ;-). It's a first step; I hope it will help some other ARM9 developers and look forward to reading some feedbacks. I profit to thank a lot the Xenomai team (Philippe, Jan, Gilles and the others) for their excellent work and support). Xenomai exists because people participate in the Sisyphean task of making it better, like you just did. In other words, welcome to the band. Let's roll the rock. Cool. Kind regards Daniel ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core -- Philippe. Daniel ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
RE : [Xenomai-core] Xenomai on Freescale i.MX21 (ARM926J)
Hi Marco, Two of our soft/hard engineers (Sébastien Gerber Guillaume Boutillier) have worked quite a lot over these last 6 months for this port. These last weeks, they spent much work on measuring the response time (by means of a digital analyzer) and trying to move some piece of code and re-work out a bit the current patch in order to make the IRQ virtualization as clean as possible and to get very low latency. Thanks to them :-) Daniel Message d'origine De: Marco Cavallini [mailto:[EMAIL PROTECTED] Date: jeu. 20.04.2006 17:36 À: xenomai-core@gna.org Cc: ROSSIER Daniel Objet : Re: [Xenomai-core] Xenomai on Freescale i.MX21 (ARM926J) ROSSIER Daniel wrote: Dear all, We finally succeeded in the port of Xenomai on our Freescale i.MX21 board (ARM-926J); (The board used is the CSB535FS issued from Cogent with the BSP from Microcross) Daniel, thank you and congratulations for this great work! I wonder how many man/hours have you spent to reach this goal ? TIA /marco ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
RE : RE : [Xenomai-core] Xenomai on Freescale i.MX21 (ARM926J)
Yes indeed; we actually intend to implement some interaction protocols between the processor and an FPGA as realtime tasks for cryptographic operations. We therefore try to have some minimal overhead. Right now, we focus on the iMX21 proc. and since we're bound to some industrial projects, we won't have much time to have a look at other archs, although we are, of course, very interested in getting some feedback on other archs and we're ready to provide some help as much as we can. We stay in touch :-) (i look forward to having further details about your micro-optimisation approach in the user space; at the moment, we mainly work RT tasks in the kernel space for architectural reasons, but migrating the code to a more convenient execution environment in the user space definitively retains our attention). By the way, I have a student who will work on an extension of LTTng (Linux trace toolkit) in order to support Xenomai, in the context of his diploma work. Examining the RT traces, filtering events, tracking RT activities in user/kernel space, detecting priority inversions, etc. are some interesting topics we're promoting in our Institute. Any ideas/suggestions about features and extensions to improve such visualization tools are also welcome :-) (we will publish everything as soon as we have some substantial results, but the student work is mainly on the second half of the Year at Montreal to the originator's premises). Daniel Message d'origine De: Jan Kiszka [mailto:[EMAIL PROTECTED] Date: ven. 21.04.2006 09:31 À: ROSSIER Daniel Cc: [EMAIL PROTECTED]; xenomai-core@gna.org Objet : Re: RE : [Xenomai-core] Xenomai on Freescale i.MX21 (ARM926J) ROSSIER Daniel wrote: Hi Marco, Two of our soft/hard engineers (Sébastien Gerber Guillaume Boutillier) have worked quite a lot over these last 6 months for this port. These last weeks, they spent much work on measuring the response time (by means of a digital analyzer) and trying to move some piece of code and re-work out a bit the current patch in order to make the IRQ virtualization as clean as possible and to get very low latency. Thanks to them :-) I guess this significant effort was related to the fact that you were hunting nanoseconds, aren't you? Well, that's great! Can we hire you for other archs as well? ;) [I also have some weird ideas regarding micro-optimisations of the user space interface.] Jan ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Xenomai on Freescale i.MX21 (ARM926J)
Philippe Gerum wrote: Btw, at first glance, I did not find any additional GPL copyrights coming with your changes in the patches, it would be better to have them, so that we always know who contributed to what, as much as possible. Ok, I was not searching for the right pattern, looking more closely to the source, I eventually found those copyright notices. Forget about this request, sorry for the noise. -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Xenomai on Freescale i.MX21 (ARM926J)
Hi Daniel,
Some comments about the Adeos patch for the i.MX21/CSB535FS board. The inlined
patch
has been rebuilt by diff'ing the vanilla Adeos 1.2-00 support with yours.
--- linux-2.6.14/arch/arm/kernel/ipipe-core.c 2006-04-21
16:17:02.0 +0200
+++ linux-2.6.14-heig/arch/arm/kernel/ipipe-core.c 2006-04-21
15:33:47.0 +0200
@@ -22,6 +22,12 @@
* Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
*
* Architecture-dependent I-PIPE core support for ARM.
+ *
+ * April 2006 :
+ * Adapted to ARM9 i.MX21/CSB535FS board with Xenomai by S.Gerber,
G.Boutillier and D.Rossier
+ * University of Applied Sciences Western Switzerland
+ * Reconfigurable Embedded Digital Systems, REDS Institute
+ *
*/
#include linux/config.h
@@ -320,11 +326,19 @@ static void __ipipe_set_decr(void)
int ipipe_tune_timer(unsigned long ns, int flags)
{
unsigned long x, ticks;
+ unsigned long us;
if (flags IPIPE_RESET_TIMER)
ticks = __ipipe_mach_ticks_per_jiffy;
else {
- ticks = ns * __ipipe_mach_ticks_per_jiffy / (10 / HZ);
+
+ /*
+ * FIXME : Temporary convert ns to us. With nanosecondes we have a
problem
+ * with overflow.
+ * ticks = ns * __ipipe_mach_ticks_per_jiffy / (10
/ HZ);
+ */
+ us = ns / 1000;
+ ticks = ((us * __ipipe_mach_ticks_per_jiffy) / 1);
This change is going to be wrong when CONFIG_HZ != 1000,
this is why HZ should remain in the picture. This said, the original expression
looks
overly complicated, something like the following should do without risking the
overflow:
- ticks = ns * __ipipe_mach_ticks_per_jiffy / (10 / HZ);
+ ticks = ns / (TICKS_PER_uSEC * 1000);
if (ticks __ipipe_mach_ticks_per_jiffy)
return -EINVAL;
diff -uNrp linux-2.6.14/arch/arm/kernel/process.c
linux-2.6.14-heig/arch/arm/kernel/process.c
--- linux-2.6.14/arch/arm/kernel/process.c 2006-04-21 16:17:02.0 +0200
+++ linux-2.6.14-heig/arch/arm/kernel/process.c2006-04-21
15:33:47.0 +0200
@@ -7,6 +7,12 @@
* 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.
+ *
+ * April 2006 :
+ * Adapted to ARM9 i.MX21/CSB535FS board with Xenomai by S.Gerber,
G.Boutillier and D.Rossier
+ * University of Applied Sciences Western Switzerland
+ * Reconfigurable Embedded Digital Systems, REDS Institute
+ *
*/
#include stdarg.h
@@ -111,7 +117,14 @@ void cpu_idle(void)
preempt_disable();
leds_event(led_idle_start);
while (!need_resched())
+/*
+ * Width idle - latenca of interrupts
+ */
+#ifndef CONFIG_IPIPE
idle();
+#else
+ ;
+#endif
Ouch. It would be saner to implement the idle mode switch one could pass
as a boot argument to the kernel (e.g. arch/i386/kernel/process.c),
accepting poll or default, instead of hard-wiring the poll mode.
leds_event(led_idle_end);
preempt_enable();
schedule();
diff -uNrp linux-2.6.14/init/Kconfig linux-2.6.14-heig/init/Kconfig
--- linux-2.6.14/init/Kconfig 2006-04-21 16:17:02.0 +0200
+++ linux-2.6.14-heig/init/Kconfig 2006-04-21 15:34:01.0 +0200
@@ -502,3 +502,20 @@ config STOP_MACHINE
help
Need stop_machine() primitive.
endmenu
+
+menu Real-time sub-system
+
The Xenomai-related stuff does not belong to the Adeos patch.
--
Philippe.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Xenomai on Freescale i.MX21 (ARM926J)
ROSSIER Daniel wrote: Dear all, We finally succeeded in the port of Xenomai on our Freescale i.MX21 board (ARM-926J); (The board used is the CSB535FS issued from Cogent with the BSP from Microcross) To have further technical references, please see there: http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=i.MX_LITEKITparentCode=i.MX21nodeId=0162468rH31143ZrDR So, you will find two patches: the first one (patch-linux-2.6.14.imx21_1.0.0) is used to patch the Linux 2.6.14 for supporting the board. Then, the second one (adeos-ipipe-2.6.14-arm-imx21-0.1.00.patch) can be used against the imx21-enabled kernel for Xenomai, simply using the prepare-kernel.sh script. The patch was originally inspired from the Integrator/ARM11 patch; thanks to its author :-) We will publish soon some results regarding the different latencies, but so far we measured about 2us between the IRQ and the timer reprogramming (at the ipipe level). The problem now is the jitter which is pretty high: about 1-2us, with some occasional peaks up to 5us. Having quite a few experience with this kind of board, we don't know if it comes from the code itself, or purely from the hardware. Any idea/suggestions would be welcome. For periodic tasks around 20us, everything works perfecly. Those results are pretty impressive actually. Assuming that you compare those figures with those obtained from traditional standalone RTOS e.g. VxWorks on the same board, the critical difference with Xenomai is that Linux is competing for the hw resources, and for instance, happily trashes the cache under Xenomai's feet when scheduling its own tasks during Xeno's idle time. Additionally, Adeos adds a small overhead due to the interrupt virtualization, in exchange of real-time predictability for their delivery. Therefore, in this respect, 5 us does not look that bad already. Are 20 us a measure of the worst-case interrupt latency (i.e. running latency -t2), or scheduling latency in user-space (i.e. running latency -t0)? I don't know to what extent this (1 or 2) patch(es) can be integrated in the official distribution; but of course we are willing to make any adaptations to fulfill the requirements for that. For the technical part, I guess that anyone interested in the ARM support for Adeos/Xenomai will review this code; I'll be one of these people, for sure. The usefulness of such contribution looks obvious to me. For the non-technical part, a pre-requisite for adding code to the Adeos or Xenomai codebases is to properly identify it as coming from a legitimate source, so if you, as a submitter, can confirm that you may freely contribute it on behalf of the HEIG-VD (I guess?) or yourself, that's fine with us. Btw, at first glance, I did not find any additional GPL copyrights coming with your changes in the patches, it would be better to have them, so that we always know who contributed to what, as much as possible. It's a first step; I hope it will help some other ARM9 developers and look forward to reading some feedbacks. I profit to thank a lot the Xenomai team (Philippe, Jan, Gilles and the others) for their excellent work and support). Xenomai exists because people participate in the Sisyphean task of making it better, like you just did. In other words, welcome to the band. Let's roll the rock. Kind regards Daniel ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Xenomai on Freescale i.MX21 (ARM926J)
ROSSIER Daniel wrote: Dear all, We finally succeeded in the port of Xenomai on our Freescale i.MX21 board (ARM-926J); (The board used is the CSB535FS issued from Cogent with the BSP from Microcross) Daniel, thank you and congratulations for this great work! I wonder how many man/hours have you spent to reach this goal ? TIA /marco ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
