Re: [Xenomai-core] v2.1 status
Philippe Gerum wrote: Here is an update regarding the way things progress on the v2.1 branch: o The build system has been deeply revamped, so that we now fully leave the burden of building Xenomai's kernel support to Linux. To this end, the code tree has been reorganized in two major sections, the first one contains the kernel-related sources (ksrc/), the other is hosting the user-space support (src/). Since the user-space portion does not need to know about the kernel sources anymore, several issues have been solved in the same move. All in all, things are way simpler than before, which seems to indicate that we are heading to the right direction. The documentation for the installation process needs to be updated though. I like it a lot. o Also as a matter of build system (and a bit more), v2.1 has been backported to Linux 2.4, starting with the ppc32 support. We rely on Denx's 2_4-devel tree as our 2.4 kernel of reference for this port [1]. A second backport to 2.4/x86 will happen when this combo is I-pipe ready. We are ahead of schedule regarding this backport, since it was initially planned for Q12006, but since we are going to add more supported architectures in the next months, it's better to have a stable build system for that. Just tested Xenomai with adeos-ipipe-2.4.25-ppc-denx-0.9-02.patch on a recent DENX kernel tree. MPC 8xx support was missing. I have attached the patch to fix it. Furthermore I have not found the Machine options (here from 2.6): # # Machine # # CONFIG_XENO_HW_FPU is not set CONFIG_XENO_HW_PERIODIC_TIMER=y CONFIG_XENO_HW_TIMER_LATENCY=1 CONFIG_XENO_HW_SCHED_LATENCY=1 The latency figures on my TQM860L board with Xenomai 2.1 and Liunx 2.4 are close to the one I measured with Xenomail 2.0 with Linux 2.6: LATENCY with load on TQM860L: Linux |-lat min|-lat avg|-latmax|-overrun|---test-time 2.6.13 | 60480| 120960| 224320| 0|00:09:46 2.4.25 | 64080| 95120| 225040| 0|00:10:00 o PowerPC-wise (again), we should be close to ready for 2.6.15, since Heikki merged both the 32 and 64-bit trees in a single one. All other tasks planned are undergoing. For my part, I'm going to fiddle now with ADI's Blackfin for which we already have the required Adeos support, and create the Xenomai port for it. Since this one is uClinux based, we should be able to check that the new build system is ok to host any kind of port sanely. [1] http://www.denx.de/en/Software/CVS/ Thanks. Have a nice weekend. Wolfgang. + diff -u linuxppc_2_4_devel-2005-11-19_1437-ipipe/arch/ppc/kernel/head_8xx.S.IPIPE2 linuxppc_2_4_devel-2005-11-19_1437-ipipe/arch/ppc/kernel/head_8xx.S --- linuxppc_2_4_devel-2005-11-19_1437-ipipe/arch/ppc/kernel/head_8xx.S.IPIPE2 2005-02-13 21:04:14.0 +0100 +++ linuxppc_2_4_devel-2005-11-19_1437-ipipe/arch/ppc/kernel/head_8xx.S 2005-11-19 14:51:27.0 +0100 @@ -231,7 +231,11 @@ bl transfer_to_handler .globl do_IRQ_intercept do_IRQ_intercept: - .long do_IRQ; +#ifdef CONFIG_IPIPE + .long __ipipe_grab_irq +#else /* !CONFIG_IPIPE */ + .long do_IRQ +#endif /* CONFIG_IPIPE */ .long ret_from_intercept /* Alignment exception */ @@ -268,7 +272,11 @@ bl transfer_to_handler .globl timer_interrupt_intercept timer_interrupt_intercept: - .long timer_interrupt +#ifdef CONFIG_IPIPE + .long __ipipe_grab_timer +#else /* !CONFIG_IPIPE */ + .long timer_interrupt +#endif /* CONFIG_IPIPE */ .long ret_from_intercept STD_EXCEPTION(0xa00, Trap_0a, UnknownException) ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Problem with #define uint i
Hallo, when trying to build RTnet with Xenomai and Linux 2.4.25 for PowerPC, I stumbeld over the following problem: In linuxppc_2_4_devel/include/asm-generic/xenomai/wrappers.h there is defined: #define ulong i #define uint i This makes trouble when a driver uses the types uint or ulong, which is the case for the MPC RTnet drivers. Can we use different names for the above definitions? Thanks. Wolfgang. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] latency kernel part fixed
Philippe Gerum wrote: Jan Kiszka wrote: Gilles Chanteperdrix wrote: Philippe Gerum wrote: Gilles Chanteperdrix wrote: Philippe Gerum wrote: Likely not this time (keep it cold anyway, who knows); I strongly suspect a bug in xnarch_switch_to() for all archs but x86 Now that you are talking about it, I may be the one who owes a beer to everyone by first having put a bug in ia64 context-switch code... If I am not wrong, the bug should be observed on ia64 too. Unfortunately, I am unable to compile my ia64 kernel right now, so I wrote a patch for power PC, and would be glad if some power PC owner could try it. Nope, same lockup with hybrid scheduling. The latency -t 1 crash may be observed on ia64 too. But it does not seem to be due to the bug I was suspecting in context switch code. What about the PPC world? I saw some SVN commits claiming to fix this (also for blackfin) - but there was no Hey, it's fixed now! on the mailing list. Ok... Hey, it's fixed now! Hybrid scheduling (kernel and user-space Xeno threads combination) has been fixed for ppc32, ppc64, ia64 and the Blackfin. Issue fixed on the ARM port to come too. Some tests remain to be conducted on the ppc64 though. The rest has already been validated. Fixes are available from the SVN trunk/. This said, here is my next Xmas wishlist I'd really appreciate you guys anticipate from, say 11 months and a couple of weeks: if you have any of the above archs, please run both the kernel and user-space latency tests on such hw: OK, I will do tests on a few PowerPC boards (4xx, 8xx, 8260). Basically, this boils down to building Jan's timerbench test into the kernel or as a separate module, then run the following tests on the said kernel: $ sudo ./latency -t0 $ sudo ./latency -t1 $ sudo ./latency -t2 Special note to the ppc32 people: I would be interested in having your feedback about switching on the ALTIVEC and SPE supports at kernel level, on platforms that do not have those beasts, and see if all tests survive this. In any case, I'm eventually going to warn about such configurations at the very least, since relying on FTR fixups right in the middle of the fast path for all context switches is kind of, mmh, silly?! Nevertheless, knowing about the result might be important in the future. TIA, ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Re: Xenomai broken on Linux 2.4
Philippe Gerum wrote: Wolfgang Grandegger wrote: Hi Philippe, I just realized that recent changes in ksrc/arch/powerpc/switch.S have broken the build of Xenomai with linuxppc_2_4_devel on PPC: #include asm/offsets.h does not exist Symbols like SAVE_NVGPRS do not exist Fixed. Thanks. Attached is a little patch fixing a build problem with Linux 2.6.14 for PowerPC (ocotea, AMCC 440GX). But I'm not sure when exactly the change happened. For the time being, I will stick with an older version for testing RTnet (where I'm currently debugging floating point used in kernel errors on the MPC8260), Thanks. Wolfgang. + diff -u linux-2.6.14-ipipe/include/asm-generic/xenomai/wrappers.h.ORIG1 linux-2.6.14-ipipe/include/asm-generic/xenomai/wrappers.h --- linux-2.6.14-ipipe/include/asm-generic/xenomai/wrappers.h.ORIG1 2006-01-12 16:13:28.95807 +0100 +++ linux-2.6.14-ipipe/include/asm-generic/xenomai/wrappers.h 2006-01-12 16:56:08.623129271 +0100 @@ -150,7 +150,7 @@ /* Device registration */ #if LINUX_VERSION_CODE = KERNEL_VERSION(2,6,13) #define DECLARE_DEVCLASS(clname) struct class *clname -#if LINUX_VERSION_CODE = KERNEL_VERSION(2,6,15) +#if LINUX_VERSION_CODE = KERNEL_VERSION(2,6,14) #define wrap_class_device_create class_device_create #else /* 2.6.15 */ #define wrap_class_device_create(c,p,dt,dv,fmt,args...) class_device_create(c,dt,dv,fmt , ##args) ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Re: Xenomai broken on Linux 2.4
Wolfgang Denk wrote: Dear Philippe, in message [EMAIL PROTECTED] you wrote: We try to find a way to wrap class_device_create properly depending on the kernel version Xeno is compiled against. The parent device class argument in this call (2nd in order) seems to show up in 2.6.15 for kernel.org, but 2.6.14-denx-git has it too. So we have a problem relying on the version sublevel. I see. Well, I feel honored, but the reference in such cases should always be Linus' tree (i. e. the official kernel.org tree). Xenomai cannot and should not have to be considerate of all the N vendor kernel trees that exist out there in the wild... And if some user should use our old 2.6.14 tree and run into problems we can just tell him to use current code - so no problem here, either. Please use kernel.org as reference (and remember that decision in case other vendors should come urging you). Philippe, for some (yet) unknown reasons the trees are not in sync but they should in respect to include/linux/device.h. Well, lets simply ignore this problem for Xenomai. Thanks. Wolfgang. Best regards, Wolfgang Denk ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Missing IRQ end function on PowerPC
Gilles Chanteperdrix wrote: Wolfgang Grandegger wrote: Therefore we need a dedicated function to re-enable interrupts in the ISR. We could name it *_end_irq, but maybe *_enable_isr_irq is more obvious. On non-PPC archs it would translate to *_irq_enable. I realized, that *_irq_enable is used in various place/skins and therefore I have not yet provided a patch. The function xnarch_irq_enable seems to be called in only two functions, xintr_enable and xnintr_irq_handler when the flag XN_ISR_ENABLE is set. But the user may want to re-enable the interrupt without using XN_ISR_ENABLE as well. In any case, since I am not sure if this has to be done at the Adeos level or in Xenomai, we will wait for Philippe to come back and decide. In both, I guess. OK and thanks. Wolfgang. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Missing IRQ end function on PowerPC
Gilles Chanteperdrix wrote:
Wolfgang Grandegger wrote:
Therefore we need a dedicated function to re-enable interrupts in the
ISR. We could name it *_end_irq, but maybe *_enable_isr_irq is more
obvious. On non-PPC archs it would translate to *_irq_enable. I
realized, that *_irq_enable is used in various place/skins and therefore
I have not yet provided a patch.
The function xnarch_irq_enable seems to be called in only two functions,
xintr_enable and xnintr_irq_handler when the flag XN_ISR_ENABLE is set.
In any case, since I am not sure if this has to be done at the Adeos
level or in Xenomai, we will wait for Philippe to come back and decide.
Attached is a temporary Xenomai patch fixing the IRQ end problem for the
PowerPC arch. I had a closer look to the various IRQ end functions on
PowerPC:
ic_end(unsigned int irq)
{
ic_ack(irq);
if (!(irq_desc[irq].status (IRQ_DISABLED | IRQ_INPROGRESS))) {
ic_enable(irq);
}
}
In most cases the end functions do the same than the begin functions but
there are exceptions where the end functions do an additional ic_ack()
as shown above.
Wolfgang.
+ diff -u xenomai/include/asm-generic/hal.h.IRQEND xenomai/include/asm-generic/hal.h
--- xenomai/include/asm-generic/hal.h.IRQEND 2006-01-11 18:03:34.0 +0100
+++ xenomai/include/asm-generic/hal.h 2006-01-19 20:52:40.0 +0100
@@ -357,6 +357,8 @@
int rthal_irq_disable(unsigned irq);
+int rthal_irq_end(unsigned irq);
+
int rthal_irq_host_request(unsigned irq,
irqreturn_t (*handler)(int irq,
void *dev_id,
+ diff -u xenomai/include/asm-generic/system.h.IRQEND xenomai/include/asm-generic/system.h
--- xenomai/include/asm-generic/system.h.IRQEND 2006-01-11 18:03:34.0 +0100
+++ xenomai/include/asm-generic/system.h 2006-01-19 20:50:17.0 +0100
@@ -496,6 +496,12 @@
return rthal_irq_disable(irq);
}
+static inline int xnarch_end_irq (unsigned irq)
+
+{
+ return rthal_irq_end(irq);
+}
+
static inline void xnarch_chain_irq (unsigned irq)
{
+ diff -u xenomai/include/asm-uvm/system.h.IRQEND xenomai/include/asm-uvm/system.h
--- xenomai/include/asm-uvm/system.h.IRQEND 2006-01-11 18:03:34.0 +0100
+++ xenomai/include/asm-uvm/system.h 2006-01-19 20:51:36.0 +0100
@@ -296,6 +296,13 @@
return -ENOSYS;
}
+static inline int xnarch_end_irq (unsigned irq)
+
+{
+return -ENOSYS;
+}
+
+
static inline void xnarch_chain_irq (unsigned irq)
{ /* Nop */ }
+ diff -u xenomai/ksrc/arch/generic/hal.c.IRQEND xenomai/ksrc/arch/generic/hal.c
--- xenomai/ksrc/arch/generic/hal.c.IRQEND 2006-01-11 18:03:42.0 +0100
+++ xenomai/ksrc/arch/generic/hal.c 2006-01-19 20:54:06.0 +0100
@@ -1156,6 +1156,7 @@
EXPORT_SYMBOL(rthal_irq_release);
EXPORT_SYMBOL(rthal_irq_enable);
EXPORT_SYMBOL(rthal_irq_disable);
+EXPORT_SYMBOL(rthal_irq_end);
EXPORT_SYMBOL(rthal_irq_host_request);
EXPORT_SYMBOL(rthal_irq_host_release);
EXPORT_SYMBOL(rthal_irq_host_pend);
+ diff -u xenomai/ksrc/arch/powerpc/hal.c.IRQEND xenomai/ksrc/arch/powerpc/hal.c
--- xenomai/ksrc/arch/powerpc/hal.c.IRQEND 2006-01-11 18:03:41.0 +0100
+++ xenomai/ksrc/arch/powerpc/hal.c 2006-01-19 21:56:19.0 +0100
@@ -356,6 +356,27 @@
return 0;
}
+int rthal_irq_end (unsigned irq)
+
+{
+if (irq = IPIPE_NR_XIRQS)
+ return -EINVAL;
+
+if (rthal_irq_descp(irq)-handler != NULL)
+{
+ if (rthal_irq_descp(irq)-handler-end != NULL)
+ rthal_irq_descp(irq)-handler-end(irq);
+ else if (rthal_irq_descp(irq)-handler-enable != NULL)
+ rthal_irq_descp(irq)-handler-enable(irq);
+ else
+ return -ENODEV;
+ }
+else
+ return -ENODEV;
+
+return 0;
+}
+
static inline int do_exception_event (unsigned event, unsigned domid, void *data)
{
+ diff -u xenomai/ksrc/nucleus/intr.c.IRQEND xenomai/ksrc/nucleus/intr.c
--- xenomai/ksrc/nucleus/intr.c.IRQEND 2006-01-11 18:03:42.0 +0100
+++ xenomai/ksrc/nucleus/intr.c 2006-01-19 20:42:53.0 +0100
@@ -363,7 +363,7 @@
++intr-hits;
if (s XN_ISR_ENABLE)
- xnarch_enable_irq(irq);
+ xnarch_end_irq(irq);
if (s XN_ISR_CHAINED)
xnarch_chain_irq(irq);
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [Combo-PATCH] Shared interrupts (final)
Jan Kiszka wrote: Wolfgang Grandegger wrote: Hello, Dmitry Adamushko wrote: Hi, this is the final set of patches against the SVN trunk of 2006-02-03. It addresses mostly remarks concerning naming (XN_ISR_ISA - XN_ISR_EDGE), a few cleanups and updated comments. Functionally, the support for shared interrupts (a few flags) to the Not directly your fault: the increasing number of return flags for IRQ handlers makes me worry that they are used correctly. I can figure out what they mean (not yet that clearly from the docs), but does someone else understand all this: - RT_INTR_HANDLED - RT_INTR_CHAINED - RT_INTR_ENABLE - RT_INTR_NOINT or - RTDM_IRQ_PROPAGATE - RTDM_IRQ_ENABLE - RTDM_IRQ_NOINT Third-party comments / suggestions welcome as well. Maybe I'm too pessimistic. rtdm (Jan's patch) and native skin. In the later case, rt_intr_create() now contains the 6-th argument, namely int mode. Now I'm waiting for the test results from Jan (the previous patch-set remains to be suitable for testing too in case you are using it already). Upon success, the new code is ready for merging. Trying to manage the priority list of someone else is tricky - I hope we can see something soon, but I cannot promise anything. the patches have to be applied as follows : - shirq-base - shirq-v8 - shirq-proc - shirq-edge - shirq-ext Happy testing ! :) My concern is code size. I see that the patches add substantial amount of code to the ISR. What about make this feature configurable? I would vote for the (already scheduled?) extension to register an optimised IRQ trampoline in case there is actually no sharing taking place. This would also make the if (irq == XNARCH_TIMER_IRQ) path obsolete. I still prefer configuration options as they also allow to reduce the overall code size (less cache refills and TLB misses). And shared interrupts are for x86 only (approximately), I think. Unfortunately, I don't have the time to follow all the details of the rapid Xenomai development and can't therefore judge what is really necessary. Wolfgang. Jan ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [Combo-PATCH] Shared interrupts (final)
Jan Kiszka wrote: Wolfgang Grandegger wrote: Hello, Dmitry Adamushko wrote: Hi, this is the final set of patches against the SVN trunk of 2006-02-03. It addresses mostly remarks concerning naming (XN_ISR_ISA - XN_ISR_EDGE), a few cleanups and updated comments. Functionally, the support for shared interrupts (a few flags) to the Not directly your fault: the increasing number of return flags for IRQ handlers makes me worry that they are used correctly. I can figure out what they mean (not yet that clearly from the docs), but does someone else understand all this: - RT_INTR_HANDLED - RT_INTR_CHAINED - RT_INTR_ENABLE - RT_INTR_NOINT or - RTDM_IRQ_PROPAGATE - RTDM_IRQ_ENABLE - RTDM_IRQ_NOINT Third-party comments / suggestions welcome as well. Maybe I'm too pessimistic. rtdm (Jan's patch) and native skin. In the later case, rt_intr_create() now contains the 6-th argument, namely int mode. Now I'm waiting for the test results from Jan (the previous patch-set remains to be suitable for testing too in case you are using it already). Upon success, the new code is ready for merging. Trying to manage the priority list of someone else is tricky - I hope we can see something soon, but I cannot promise anything. the patches have to be applied as follows : - shirq-base - shirq-v8 - shirq-proc - shirq-edge - shirq-ext Happy testing ! :) My concern is code size. I see that the patches add substantial amount of code to the ISR. What about make this feature configurable? I would vote for the (already scheduled?) extension to register an optimised IRQ trampoline in case there is actually no sharing taking place. This would also make the if (irq == XNARCH_TIMER_IRQ) path obsolete. I still prefer configuration options as they also allow to reduce the overall code size (less cache refills and TLB misses). And shared interrupts are for x86 only (approximately), I think. Unfortunately, I don't have the time to follow all the details of the rapid Xenomai development and can't therefore judge what is really necessary. Wolfgang. Jan
[Xenomai-core] Problem with #define uint i
Hallo, when trying to build RTnet with Xenomai and Linux 2.4.25 for PowerPC, I stumbeld over the following problem: In linuxppc_2_4_devel/include/asm-generic/xenomai/wrappers.h there is defined: #define ulong i #define uint i This makes trouble when a driver uses the types uint or ulong, which is the case for the MPC RTnet drivers. Can we use different names for the above definitions? Thanks. Wolfgang.
[Xenomai-core] Xenomai broken on Linux 2.4
Hi Philippe, I just realized that recent changes in ksrc/arch/powerpc/switch.S have broken the build of Xenomai with linuxppc_2_4_devel on PPC: #include asm/offsets.h does not exist Symbols like SAVE_NVGPRS do not exist For the time being, I will stick with an older version for testing RTnet (where I'm currently debugging floating point used in kernel errors on the MPC8260), Thanks. Wolfgang.
[Xenomai-core] Re: Xenomai broken on Linux 2.4
Philippe Gerum wrote: Wolfgang Grandegger wrote: Philippe Gerum wrote: Wolfgang Grandegger wrote: Hi Philippe, I just realized that recent changes in ksrc/arch/powerpc/switch.S have broken the build of Xenomai with linuxppc_2_4_devel on PPC: #include asm/offsets.h does not exist Symbols like SAVE_NVGPRS do not exist Fixed. Thanks. Attached is a little patch fixing a build problem with Linux 2.6.14 for PowerPC (ocotea, AMCC 440GX). But I'm not sure when exactly the change happened. Looks like specific to 2.6.14-DENX (kernel.org shows the additional parent parameter only starting with 2.6.15). http://www.denx.de/cgi-bin/gitweb.cgi?p=linux-2.6-denx.git;a=blobdiff;h=a9e72ac3fb9fd066ebc5607bd28cfdd4ba8f010e;hp=95d607a48f06edd22c6be64e0feaf74d1aa63467;hb=3692e2d8099f19a4d1ff95df94cc82b394f86931;f=include/linux/device.h We likely need to find a way to specifically identify this tree. Well, our 2.6 tree is based on the offical 2.6 tree. Don't know where the difference come from. Maybe Wolfgang can help (he is now on CC). For the time being, I will stick with an older version for testing RTnet (where I'm currently debugging floating point used in kernel errors on the MPC8260), Thanks. Wolfgang. + diff -u linux-2.6.14-ipipe/include/asm-generic/xenomai/wrappers.h.ORIG1 linux-2.6.14-ipipe/include/asm-generic/xenomai/wrappers.h --- linux-2.6.14-ipipe/include/asm-generic/xenomai/wrappers.h.ORIG1 2006-01-12 16:13:28.95807 +0100 +++ linux-2.6.14-ipipe/include/asm-generic/xenomai/wrappers.h 2006-01-12 16:56:08.623129271 +0100 @@ -150,7 +150,7 @@ /* Device registration */ #if LINUX_VERSION_CODE = KERNEL_VERSION(2,6,13) #define DECLARE_DEVCLASS(clname) struct class *clname -#if LINUX_VERSION_CODE = KERNEL_VERSION(2,6,15) +#if LINUX_VERSION_CODE = KERNEL_VERSION(2,6,14) #define wrap_class_device_create class_device_create #else /* 2.6.15 */ #define wrap_class_device_create(c,p,dt,dv,fmt,args...) class_device_create(c,dt,dv,fmt , ##args)
Re: [Xenomai-core] Re: Xenomai broken on Linux 2.4
Wolfgang Denk wrote: Dear Philippe, in message [EMAIL PROTECTED] you wrote: We try to find a way to wrap class_device_create properly depending on the kernel version Xeno is compiled against. The parent device class argument in this call (2nd in order) seems to show up in 2.6.15 for kernel.org, but 2.6.14-denx-git has it too. So we have a problem relying on the version sublevel. I see. Well, I feel honored, but the reference in such cases should always be Linus' tree (i. e. the official kernel.org tree). Xenomai cannot and should not have to be considerate of all the N vendor kernel trees that exist out there in the wild... And if some user should use our old 2.6.14 tree and run into problems we can just tell him to use current code - so no problem here, either. Please use kernel.org as reference (and remember that decision in case other vendors should come urging you). Philippe, for some (yet) unknown reasons the trees are not in sync but they should in respect to include/linux/device.h. Well, lets simply ignore this problem for Xenomai. Thanks. Wolfgang. Best regards, Wolfgang Denk
[Xenomai-core] Xenomai t0-2 latency measurements
Hello, attached you will find the results of my todays Xenomai latency measurements on various PowerPC boards with Linux 2.4 and 2.6. Wolfgang. New latency tests with Xenomai on various PowerPC boards Board : Processor CPU-Clk Bus-Clk I-Cache D-Cache Memory Kernel Remarks TQM860L : MPC 860 50 MHz 50 MHz4 KB4 kB 16 MB 2.4.25 PM825 : MPC 8260 200 MHz 66 MHz 16 KB 16 kB 128 MB 2.4.25 FPU Ocotea : AMCC 440GX 533 MHz 152 MHz 32 KB 32 KB 256 MB 2.6.14 DDR-RAM, L2 256 KB Linux : DENX Linux 2.6.14 or DENX Linux 2.4.25 (linuxppc_2_4_devel) iPipe : 1.0-02 or 1.1-02 Xenomai: SVN 2006-01-12 LATENCY on TQM860L with load (and -p500): |-lat min|-lat avg|-lat max|-overrun|---test-time -t0 | 58240| 122240| 217280| 0|00:05:00 -t1 | 64480| 97584| 160320| 0|00:05:00 -t2 | 24640| 48961| 105280| 0|00:05:00 LATENCY on PM825 with load: |-lat min|-lat avg|-lat max|-overrun|---test-time -t0 | 17750| 29125| 64062| 0|00:05:00 -t1 | 10188| 22413| 50188| 0|00:05:00 -t2 | 15062| 10754| 38438| 0|00:05:00 LATENCY on Ocotea with load: |-lat min|-lat avg|-lat max|-overrun|---test-time -t0 |4897| 10815| 27774| 0|00:05:00 -t1 |3423|8316| 23935| 0|00:05:00 -t2 |1714|3701| 12010| 0|00:05:00 Note: load has been put onto the system by running in a telnet session ping -f remote-host-ip and calibrator ... (Cache-Memory and TLB Calibration Tool http://monetdb.cwi.nl/Calibrator/). Note: all test have been run with CONFIG_XENO_HW_TIMER_LATENCY=1 and CONFIG_XENO_HW_SCHED_LATENCY=1 to get correct latancy values. Old latency measurements: - Linux : DENX linux-2.6.14-rc3-g4c234921 iPipe : 1.0-00 Xenomai: SVN 2005-10-15 KLATENCY with load: |-lat min|-lat avg|-lat max|-overrun|---test-time TQM860L | 50560| 98976| 199040| 0|00:09:45 Ocotea |2953|5974| 19147| 0|00:12:05 LATENCY with load: |-lat min|-lat avg|-lat max|-overrun|---test-time TQM860L | 60480| 120960| 224320| 0|00:09:46 Ocotea |3575|7438| 24474| 0|00:10:50
Re: [Xenomai-core] Missing IRQ end function on PowerPC
Gilles Chanteperdrix wrote: Wolfgang Grandegger wrote: Therefore we need a dedicated function to re-enable interrupts in the ISR. We could name it *_end_irq, but maybe *_enable_isr_irq is more obvious. On non-PPC archs it would translate to *_irq_enable. I realized, that *_irq_enable is used in various place/skins and therefore I have not yet provided a patch. The function xnarch_irq_enable seems to be called in only two functions, xintr_enable and xnintr_irq_handler when the flag XN_ISR_ENABLE is set. But the user may want to re-enable the interrupt without using XN_ISR_ENABLE as well. In any case, since I am not sure if this has to be done at the Adeos level or in Xenomai, we will wait for Philippe to come back and decide. In both, I guess. OK and thanks. Wolfgang.
Re: [Xenomai-core] Missing IRQ end function on PowerPC
This is an OpenPGP/MIME signed message (RFC 2440 and 3156) Philippe Gerum wrote: Jan Kiszka wrote: Wolfgang Grandegger wrote: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) Philippe Gerum wrote: Gilles Chanteperdrix wrote: Wolfgang Grandegger wrote: Therefore we need a dedicated function to re-enable interrupts in the ISR. We could name it *_end_irq, but maybe *_enable_isr_irq is more obvious. On non-PPC archs it would translate to *_irq_enable. I realized, that *_irq_enable is used in various place/skins and therefore I have not yet provided a patch. The function xnarch_irq_enable seems to be called in only two functions, xintr_enable and xnintr_irq_handler when the flag XN_ISR_ENABLE is set. In any case, since I am not sure if this has to be done at the Adeos level or in Xenomai, we will wait for Philippe to come back and decide. -enable() and -end() all mixed up illustrates a silly x86 bias I once had. We do need to differentiate the mere enabling from the IRQ epilogue at PIC level since Linux does it - i.e. we don't want to change the semantics here. I would go for adding xnarch_end_irq - rthal_irq_end to stick with the Linux naming scheme, and have the proper epilogue done from there on a per-arch basis. Current uses of xnarch_enable_irq() should be reserved to the non-epilogue case, like xnintr_enable() i.e. forcibly unmasking the IRQ source at PIC level outside of any ISR context for such interrupt (*). XN_ISR_ENABLE would trigger a call to xnarch_end_irq, instead of xnarch_enable_irq. I see no reason for this fix to leak to the Adeos layer, since the HAL already controls the way interrupts are ended actually; it just does it improperly on some platforms. (*) Jan, does rtdm_irq_enable() have the same meaning, or is it intended to be used from the ISR too in order to revalidate the source at PIC level? Nope, rtdm_irq_enable() was never intended to re-enable an IRQ line after an interrupt, and the documentation does not suggest this either. I see no problem here. But RTDM needs a rtdm_irq_end() functions as well in case the user wants to reenable the interrupt outside the ISR, I think. If this is a valid use-case, it should be really straightforward to add this abstraction to RTDM. We should just document that rtdm_irq_end() shall not be invoked from IRQ context - It's the other way around: -end() would indeed be called from the ISR epilogue, and -enable() would not. I think we are talking about different things: Wolfgang was asking for an equivalent of RTDM_IRQ_ENABLE outside the IRQ handler. That's the user API. You are now referring to the back-end which had to provide some end-mechanism to be used both by the nucleus' ISR epilogue and that rtdm_irq_end(), and that mechanism shall be told apart from the IRQ enable/disable API. Well, that's at least how I think to have got it... Yep, I was thinking of deferred interrupt handling in a real-time task. Then rtdm_irq_end() would be required. to avoid breaking the chain in the shared-IRQ scenario. RTDM_IRQ_ENABLE must remain the way to re-enable the line from the handler. Jan Jan Wolfgang.
Re: [Xenomai-core] Dev branch 2.1
Philippe Gerum wrote: Hannes Mayer wrote: Ciao Philippe! prepare-kernel.sh works well - I'd suggest to ask the user for the 3 needed parameters, instead of supplying them as parameters. e.g. # scripts/prepare-kernel.sh Linux directory: [default: /usr/src/linux] : Adeos-patch: [default: none] : Architecture: [default: i386] ...or something like that. Yep, good idea. ./configure also went well, but then: # make Making all in src make[1]: Entering directory `/usr/src/xenomai-2.1/src' Making all in include make[2]: Entering directory `/usr/src/xenomai-2.1/src/include' make all-recursive make[3]: Entering directory `/usr/src/xenomai-2.1/src/include' Making all in asm-uvm make[4]: Entering directory `/usr/src/xenomai-2.1/src/include/asm-uvm' make[4]: stat:system.h: Too many levels of symbolic links make[4]: *** No rule to make target `system.h', needed by `all-am'. Stop. make[4]: Leaving directory `/usr/src/xenomai-2.1/src/include/asm-uvm' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/usr/src/xenomai-2.1/src/include' make[2]: *** [all] Error 2 make[2]: Leaving directory `/usr/src/xenomai-2.1/src/include' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/src/xenomai-2.1/src' make: *** [all-recursive] Error 1 /usr/src/xenomai-2.1/src/include/asm-uvm# ll total 36 -rw-r--r-- 1 root root 12780 2005-11-03 01:03 Makefile -rw-r--r-- 1 cap cap 67 2005-11-02 21:36 Makefile.am -rw-r--r-- 1 cap cap 13046 2005-11-02 21:36 Makefile.in lrwxrwxrwx 1 root root39 2005-11-03 01:03 system.h - ../../.././src/include/asm-uvm/system.h Try building out of the source tree; it's something I'm likely going to enforce anyway. I have realized the same error building out of the source tree for PowerPC. The problem is, that the link is pointing to itself. Apart from that, the ksrc part works fine (at least I can boot the ipipe kernel). Thanks. Wolfgang.
Re: [Xenomai-core] Dev branch 2.1
Hannes Mayer wrote: Wolfgang Grandegger wrote: [...] I have realized the same error building out of the source tree for PowerPC. The problem is, that the link is pointing to itself. Apart from that, the ksrc part works fine (at least I can boot the ipipe kernel). If I remove the sym-link and copy .svn/text-base/system.h.svn-base to src/include/asm-uvm/system.h it compliles: muon:/usr/src/xenomai-2.1/src/include/asm-uvm# ll total 36 -rw-r--r-- 1 root root 12780 2005-11-03 01:03 Makefile -rw-r--r-- 1 cap cap 67 2005-11-02 21:36 Makefile.am -rw-r--r-- 1 cap cap 13046 2005-11-02 21:36 Makefile.in lrwxrwxrwx 1 root root39 2005-11-03 01:03 system.h - ../../.././src/include/asm-uvm/system.h muon:/usr/src/xenomai-2.1/src/include/asm-uvm# rm system.h rm: remove symbolic link `system.h'? y muon:/usr/src/xenomai-2.1/src/include/asm-uvm# cp .svn/text-base/system.h.svn-base system.h OK, so far so good. The ipipe kernel boots, I've got a directory /usr/xenomai/ with all accustomed directories, but no modules... Wolfgang, do you have the e.g. xeno_native.ko somewhere ? The Xenomai nucleus is now intergrated into the Linux kernel and if you have selected static linking, no modules will be generated. Have a look to the Xenomai kernel options (using make memnuconfig and friends). Wolfgang.
Re: [Xenomai-core] v2.1 status
Philippe Gerum wrote: Here is an update regarding the way things progress on the v2.1 branch: o The build system has been deeply revamped, so that we now fully leave the burden of building Xenomai's kernel support to Linux. To this end, the code tree has been reorganized in two major sections, the first one contains the kernel-related sources (ksrc/), the other is hosting the user-space support (src/). Since the user-space portion does not need to know about the kernel sources anymore, several issues have been solved in the same move. All in all, things are way simpler than before, which seems to indicate that we are heading to the right direction. The documentation for the installation process needs to be updated though. I like it a lot. o Also as a matter of build system (and a bit more), v2.1 has been backported to Linux 2.4, starting with the ppc32 support. We rely on Denx's 2_4-devel tree as our 2.4 kernel of reference for this port [1]. A second backport to 2.4/x86 will happen when this combo is I-pipe ready. We are ahead of schedule regarding this backport, since it was initially planned for Q12006, but since we are going to add more supported architectures in the next months, it's better to have a stable build system for that. Just tested Xenomai with adeos-ipipe-2.4.25-ppc-denx-0.9-02.patch on a recent DENX kernel tree. MPC 8xx support was missing. I have attached the patch to fix it. Furthermore I have not found the Machine options (here from 2.6): # # Machine # # CONFIG_XENO_HW_FPU is not set CONFIG_XENO_HW_PERIODIC_TIMER=y CONFIG_XENO_HW_TIMER_LATENCY=1 CONFIG_XENO_HW_SCHED_LATENCY=1 The latency figures on my TQM860L board with Xenomai 2.1 and Liunx 2.4 are close to the one I measured with Xenomail 2.0 with Linux 2.6: LATENCY with load on TQM860L: Linux |-lat min|-lat avg|-latmax|-overrun|---test-time 2.6.13 | 60480| 120960| 224320| 0|00:09:46 2.4.25 | 64080| 95120| 225040| 0|00:10:00 o PowerPC-wise (again), we should be close to ready for 2.6.15, since Heikki merged both the 32 and 64-bit trees in a single one. All other tasks planned are undergoing. For my part, I'm going to fiddle now with ADI's Blackfin for which we already have the required Adeos support, and create the Xenomai port for it. Since this one is uClinux based, we should be able to check that the new build system is ok to host any kind of port sanely. [1] http://www.denx.de/en/Software/CVS/ Thanks. Have a nice weekend. Wolfgang. + diff -u linuxppc_2_4_devel-2005-11-19_1437-ipipe/arch/ppc/kernel/head_8xx.S.IPIPE2 linuxppc_2_4_devel-2005-11-19_1437-ipipe/arch/ppc/kernel/head_8xx.S --- linuxppc_2_4_devel-2005-11-19_1437-ipipe/arch/ppc/kernel/head_8xx.S.IPIPE2 2005-02-13 21:04:14.0 +0100 +++ linuxppc_2_4_devel-2005-11-19_1437-ipipe/arch/ppc/kernel/head_8xx.S 2005-11-19 14:51:27.0 +0100 @@ -231,7 +231,11 @@ bl transfer_to_handler .globl do_IRQ_intercept do_IRQ_intercept: - .long do_IRQ; +#ifdef CONFIG_IPIPE + .long __ipipe_grab_irq +#else /* !CONFIG_IPIPE */ + .long do_IRQ +#endif /* CONFIG_IPIPE */ .long ret_from_intercept /* Alignment exception */ @@ -268,7 +272,11 @@ bl transfer_to_handler .globl timer_interrupt_intercept timer_interrupt_intercept: - .long timer_interrupt +#ifdef CONFIG_IPIPE + .long __ipipe_grab_timer +#else /* !CONFIG_IPIPE */ + .long timer_interrupt +#endif /* CONFIG_IPIPE */ .long ret_from_intercept STD_EXCEPTION(0xa00, Trap_0a, UnknownException)
Re: [Xenomai-core] PATCH: fix ppc64 calibration
On 10/11/2005 05:11 PM Fillod Stephane wrote: Heikki Lindholm wrote: [..] Probably, but there are less than awesome 4xx boards around and I'd guess they might even be more likely targets than G4 based machines, for example. Some tuning might be needed. How many people are using Xenomai (or Fusion) on 4xx ? What are their typical sched latency ? RTAI is used on 4xx and other embedded PowerPC processors, like 8xx, 8xxx and 52xx and Xenomai/Fusion might be an option in the future. Today, there are only a few people running and testing Xenomai/Fusion on these PowerPC processors, I guess. The problem is the availability of the Linux 2.6 together with the ADEOS/iPipe-Patch. A lot of embedded PowerPC boards do still not run or even compile Linux 2.6. Depending on the CPU power and cache size, latencies can go up to 200 us (or more), e.g. on a MPC 850 with 50 MHz and 1K cache. I'm going to measure the latency on a Ocotea (440GP) and Ebony (405) board this week (with adeos-linux-2.6.10-ppc-r8c4.patch and Fusion 0.9.1). Wolfgang.
Re: [Xenomai-core] PATCH: fix ppc64 calibration
On 10/12/2005 02:51 PM Heikki Lindholm wrote: Wolfgang Grandegger kirjoitti: On 10/11/2005 05:11 PM Fillod Stephane wrote: Heikki Lindholm wrote: [..] Probably, but there are less than awesome 4xx boards around and I'd guess they might even be more likely targets than G4 based machines, for example. Some tuning might be needed. How many people are using Xenomai (or Fusion) on 4xx ? What are their typical sched latency ? Attached is the result of some latency measurements on the Ocotea eval board. The AMCC 440 GX is already a fast 4xx processor. Unfortunately, the linuxppc-2.6.10rc3 does not run on our Ebony board. Nevertheless, it's difficult to provide a resonable default value. Why not simply using 0 and it's then up to the user to provide an appropriate value at configuration time? 0? No machine is that fast. For the 32-bit ppc it might be harder to provide a reasonable default, because of the broader scale of hardware, but I'd guess that 100MHz targets prefer to use a dedicated RTOS instead of Xenomai. For the 64-bit targets, I didn't find slower than There are a lot of 32 bit CPUs 100 MHz running Linux and sometimes they even need a realtime extension. 400 MHz machines and they were iSeries, which, I suppose, also aren't prime target for Xenomai. Regardless of what default value is used, there could be some examples provided by the config help to direct user to the right direction. I fully agree. What's the problem with Ebonys? I remember running at least 2.6.9 on Ebonys (440GP) and Walnuts (405). We have linux-2.4.14-rc3 running on all AMCC eval boards (see http://www.denx.de). But the kernel supported by RTAI/Fusion, linuxppc-2.6.10rc3, does not boot on Ebony. The main problem is the missing support for U-Boot but there might be others. And it's simply not worth the effort to port it, I think. Wolfgang.
Re: [Xenomai-core] PATCH: fix ppc64 calibration
On 10/12/2005 03:16 PM Fillod Stephane wrote: Wolfgang Grandegger wrote: On 10/11/2005 05:11 PM Fillod Stephane wrote: Heikki Lindholm wrote: [..] Probably, but there are less than awesome 4xx boards around and I'd guess they might even be more likely targets than G4 based machines, for example. Some tuning might be needed. How many people are using Xenomai (or Fusion) on 4xx ? What are their typical sched latency ? Attached is the result of some latency measurements on the Ocotea eval board. The AMCC 440 GX is already a fast 4xx processor. Unfortunately, the linuxppc-2.6.10rc3 does not run on our Ebony board. Nevertheless, it's difficult to provide a resonable default value. Why not simply using 0 and it's then up to the user to provide an appropriate value at configuration time? If it helps, know there's 2.6.10 and 2.6.11 (CONFIG_PREEMPT disabled though) ADEOS patches available for ppc. I'm using adeos-linux-2.6.10-ppc-r8c4.patch with linuxppc-2.6.10rc3, which works fine, at least on the Ocotea board. My latency measurements for Freescale e500 are here: https://mail.gna.org/public/rtai-dev/2005-02/msg00045.html It looks like an ADEOS/I-Pipe patch for current Linux kernels is much expected. Of course. But Phillips is already heavily loaded with the project, I assume. The default calibration value may be set according to L1_CACHE_BYTES. Of course I'm fine with a default value set to 0, which is closer to my end of the spectrum :-) The nice thing with 0 is that you do not get negative latency values. But for me, any number is OK. Wolfgang.
[Xenomai-core] Re: 2.4 vs 2.6 in embedded space
On 10/12/2005 04:39 PM Philippe Gerum wrote: Wolfgang Grandegger wrote: We have linux-2.4.14-rc3 running on all AMCC eval boards (see http://www.denx.de). But the kernel supported by RTAI/Fusion, linuxppc-2.6.10rc3, does not boot on Ebony. The main problem is the missing support for U-Boot but there might be others. And it's simply not worth the effort to port it, I think. Open question: to your opinion, is 2.6 on low-end embedded hw doomed by design and why, or do you think that part of the reluctance to move to 2.6 is mostly explained because 2.4 is just fine and up to the task, IOW it's kind of a don't fix if it ain't broken perception? As Wolfgang (Denk) already pointed out, 2.6 is less attractive on low end systems, because it's bigger, slower, ... This is also true for Xenomai (RTAI/fusion). It's difficult to beat the latency value of the old RTAI/RTHAL under 2.4. You need more CPU power and resources, that's how thing are going. Nevertheless, compared to the realtime preemption patch, Xenomai is _lightweight_ :-). Furthermore I think, that part of the reluctance is also due to development in progress including features like the realtime preemption patch, especially on embedded PowerPC systems. People are waiting that things get available and stable. Wolfgang.
[Xenomai-core] Re: 2.4 vs 2.6 in embedded space
On 10/13/2005 11:11 AM Philippe Gerum wrote: Wolfgang Grandegger wrote: On 10/12/2005 04:39 PM Philippe Gerum wrote: Wolfgang Grandegger wrote: We have linux-2.4.14-rc3 running on all AMCC eval boards (see http://www.denx.de). But the kernel supported by RTAI/Fusion, linuxppc-2.6.10rc3, does not boot on Ebony. The main problem is the missing support for U-Boot but there might be others. And it's simply not worth the effort to port it, I think. Open question: to your opinion, is 2.6 on low-end embedded hw doomed by design and why, or do you think that part of the reluctance to move to 2.6 is mostly explained because 2.4 is just fine and up to the task, IOW it's kind of a don't fix if it ain't broken perception? As Wolfgang (Denk) already pointed out, 2.6 is less attractive on low end systems, because it's bigger, slower, ... This is also true for Xenomai (RTAI/fusion). It's difficult to beat the latency value of the old RTAI/RTHAL under 2.4. You need more CPU power and resources, that's how thing are going. Nevertheless, compared to the realtime preemption patch, Xenomai is _lightweight_ :-). I think so too; that's the problem with strictly native real-time support in the kernel: you must end up with some kind of SMPish structure which virtually exhibits an infinite number of processors (one per task basically), so it's not going to help reducing the cpu footprints and the various noisy artefacts implied by the generalized mutex approach (which is otherwise sound, that's no the issue). This is also why there is still space for real-time extensions, provided - I think - they run as symbiotically as possible with Linux, so that we don't end up telling people to ignore they have Linux while running their apps over it. I agree and I'm really interested to get the benchmark comparison tests http://www.opersys.com/lrtbf/index.html running on a low-end PowerPC system. As far as Xeno is concerned, we should be able to continue to reduce those footprints. From my window, I see two aspects we need to work on: - impact of the Adeos pipelining on cache especially for hw with sluggish memory bandwidth - a better placement of the hot data that are accessed inside the fast interrupt path (mainly those of the scheduler). That would be nice, indeed. I also understood, that iPIPE is already lighter than ADEOS. Looking at the ppc figures since early 2005 or so, the raw latency has continuously been reduced, i.e. we went from ~120 us on a Freescale's Icecube running the user-space test, to 53 us as measured recently with 0.9.1+r8c4. I did not manage to check again on the Sandpoint (connection problem to the Vlab) which is very representative of the low-end hw issues we could face [and basically made me cry when I first looked at the latency reports], but I suspect that thing might have progressed there too. I've recently ported 0.9.1 over a Mvista kernel (experimental PREEMPT_RT-like stuff + other patches) on a mpc8541, and the figures for user-space are ~22 us worst-cast lat. Of course, this is not what one would call a sluggish low-end hw and I agree that a more structured design like Xeno can't beat a flat ISR-based design, but still, in any case, I'm optimistic enough to think that we likely have a margin of improvement there. When the iPIPE-Patch for PowerPC is available for a recent 2.6 kernel version, I could run benchmark tests on various PowerPC systems, e.g. on 4xx processors from AMCC, including a rather low-end 405 at 200 MHz. Furthermore I think, that part of the reluctance is also due to development in progress including features like the realtime preemption patch, especially on embedded PowerPC systems. People are waiting that things get available and stable. Well, we might all have the same problem here... Wolfgang.
Re: [Xenomai-core] Future of fusion
On 10/13/2005 03:33 PM Philippe Gerum wrote: Paul wrote: Hi Philippe On Thursday 13 October 2005 09:24, Philippe Gerum wrote: - Regular automated benchmarking: What is Xenomai currently capable of, how stable is it, do we progress or regress over time and releases, arch by arch? Have a couple of x86 development boxes running 24/7 - Could set one up as a compile farm for running automated builds. That would be great, thanks. Let us know if we could help. Also have a PowerPC thin client that I would like to utilise, but could really do with some help in setting up the tools for cross-compiling the base system under Debian. What about DENX's ELDK? - Configuration, building and packaging issues: Could we make this easier? Anything that involves patching/compiling kernels is bound to cause trouble for new users. Perhaps some tests for kernel options known to cause trouble (such as APM REGPARM) that print out large warnings during the config stage might help.. Ok, I have something rather highly ranked on my TODO list (which ends up by 2117 or so), which is about allowing to build all Xenomai's in-kernel support statically in the Linux kernel. The rationale behind that is about making more straightforward and efficient embedded setups; straightforward because modules add more complexity than they would solve in typical embedded systems, and efficient since loading modules in a running kernel doesn't come for free. That would be great for embedded systems, indeed. Apart from getting rid of the module infrastructure, it also save TLB misses because modules are typically placed in vmalloc'ed space. Systems with small TLB entry tables will benefit, like PowerPC 8xx and 4xx. To do that, portions of the Xeno build system which are currently autoconfiscated should move to the target kernel, so that we would only keep the autoconf infrastructure for what it's good at, i.e. building the user-space support. The basic idea is that we would then have a kernel extension part either buildable statically or as modules using Linux's Kconfig/Kbuild infrastructure, and a user-space support package providing the various interface libraries, headers, tools and scripts, ala glibc. The immediate advantages would be: - The core of the Xenomai support would be statically embeddable in the Linux kernel; - No need for a Kconfig duplication like we have now; most of the options currently presented by Xeno's Kconfig sub-system concern the kernel portions, and very few actually concern the user-space stuff. We would then get rid of the former, and rely on the vanilla Linux's one instead. - Centralizing Xenomai's kernel-related options with Linux's ones would make easier defining sanity checks (e.g. APM stuff and so on), since we could use the Kconfig language to enforce them in order to obtain sane configurations by construction (e.g. CONFIG_XENO disables CONFIG_APM). Currently, Xeno's Kconfig is not aware of the kernel settings, so the checks are performed afterwise by the configure script instead. - Removing the module compilation logic from the autoconfiscated Makefiles would be a significant simplification of the Xeno build system, and would make it less dependent on the kernel build system. - This build process is still fully automatable. - LKML people among my co-workers (Hi Stelian!) would start talking to me again, since I would stop pretending that autoconf is a sane way of controlling builds for kernel-based code. :o The way I see a typical build process would then be along these lines: $ tar jxf xenomai-* $ mkdir xeno-build cd xeno-build ../xenomai-*/configure --kernel=/usr/src/linux --some-option-only-for-uspace-stuff --prefix=install-dir (the configure script would then prepare the autoconf _and_ make the necessary links from the target kernel to the Xenomai source tree to connect the modules to the kernel's Kbuild/Kconfig infrastructure. $ cd /usr/src/linux $ make gconfig The user would configure his kernel, and all the kernel-based Xenomai stuff, as if they were standard drivers/extensions $ make the_kernel $ cd xeno-build make install And we would be done. Well, in a perfect world, I mean. Gilles already has a tarball of the Debian rules I used for packaging fusion. With minor changes, these could be used for a Xenomai package. One possibility is to use the rules and the compile farm to produce ready to run kernel/Xenomai Debian packages. I think we should be able to work this out will Gilles before 2.0 is out since it's a separate build-related issue. Regards, Paul.
[Xenomai-core] Testing the adeos-ipipe-2.6.13-ppc-1.0-00.patch
Hello Philippe, I got Xenomai working on a Ocotea-Board (AMCC 440GX) and a low-end TQM855L-Module (MPC 855) under Linux 2.6.14-rc3 :-). The patch applied with a few hunks and one easy to fix reject and I had to correct two problems. One with FEW_CONTEXT (see attached patch) and the second with #include asm/offsets.h in xenomai/arch/ppc/hal/switch.S. The include file does not exist (any more) in the kernel tree and therefore I commented out the line. I'm going to perform latency tests on various 4xx and 8xx boards next week. Here are some preliminary figures of the TQM855L-Module (CPU 80 MHz, Bus 40 MHz, 4 kB I-Cache 4 kB D-Cache): bash-2.05b# ./cruncher -p 500 Calibrating cruncher...3025953, 334, 334, 334, 334, done -- ideal computation time = 334 us. 1000 samples, 1000 hz freq (pid=338, policy=SCHED_FIFO, prio=99) Nanosleep jitter: min = 118 us, max = 474 us, avg = 155 us Execution jitter: min = 32 us (9%), max = 100 us (29%), avg = 47 us (14%) bash-2.05b# ./switch -p 500 == Sampling period: 500 us == Do not interrupt this program RTH| lat min| lat avg| lat max|lost RTD| 110400| 120200| 206600| 0 bash-2.05b# ./latency -p 500 == Sampling period: 500 us ---|||||- RTS| 7| 84000| 183200| 0|00:00:50/00:00:50 Have a nice weekend. Wolfgang. + diff -u linux-2.6.14-rc3-g4c234921-ipipe/arch/ppc/kernel/ipipe-root.c.FEW_CONTEXTS linux-2.6.14-rc3-g4c234921-ipipe/arch/ppc/kernel/ipipe-root.c --- linux-2.6.14-rc3-g4c234921-ipipe/arch/ppc/kernel/ipipe-root.c.FEW_CONTEXTS 2005-10-15 12:03:40.0 +0200 +++ linux-2.6.14-rc3-g4c234921-ipipe/arch/ppc/kernel/ipipe-root.c 2005-10-15 13:56:29.0 +0200 @@ -35,6 +35,7 @@ #include asm/atomic.h #include asm/io.h #include asm/time.h +#include asm/mmu_context.h extern irq_desc_t irq_desc[];
Re: [Xenomai-core] Testing the adeos-ipipe-2.6.13-ppc-1.0-00.patch
On 10/15/2005 09:17 PM Heikki Lindholm wrote: Wolfgang Grandegger kirjoitti: Hello Philippe, I got Xenomai working on a Ocotea-Board (AMCC 440GX) and a low-end TQM855L-Module (MPC 855) under Linux 2.6.14-rc3 :-). The patch applied with a few hunks and one easy to fix reject and I had to correct two problems. One with FEW_CONTEXT (see attached patch) and the second with #include asm/offsets.h in xenomai/arch/ppc/hal/switch.S. The include file does not exist (any more) in the kernel tree and therefore I commented out the line. I'm going to perform latency tests on various 4xx and 8xx boards next week. Here are some preliminary figures of the TQM855L-Module (CPU 80 MHz, Bus 40 MHz, 4 kB I-Cache 4 kB D-Cache): If you happen to know some (semi-)comparable figures for the same boards using some commercial RTOS, it would be nice to know them also, for comparison. Well, we only deal with free software. But I can compare the result from the klatency test with the one from RTAI/RTHAL under Linux 2.4, of course. Wolfgang.
[Xenomai-core] Xenomai latency tests on various PowerPC boards
Hallo, attached you will find the results of Xemonai latency measurements on various embedded PowerPC boards using MPC 8xx and AMCC 4xx processors, from low to high end covering a worst case latency range from 25 to 225 us. It also includes a comparison with RTAI 3.0r5 on the slowest CPU. Here are some remarks and comments: - On low-end processor code size matters a lot and it's difficult to beat RTAI/RTHAL. - Apart from the CPU power, big caches and a fast memory interface improves latencies. - L2 cache improves latencies a lot (compare Ocotea with Yosemite). - I'm a bit puzzled about the results of the cruncher test. Could someone explain the output, please? - Stability seems already quite good. At least I did not observe any crash yet :-). The PowerPC port of Xenomai is already in good shape. That's great! Wolfgang. Latency tests with Xenomai on various PowerPC boards Board : Processor CPU-Clk Bus-Clk I-Cache D-Cache Memory Remarks TQM860L : MPC 860 50 MHz 50 MHz4 KB4 kB 16 MB TQM866M : MPC 866133 MHz 66 MHz 16 KB8 kB 128 MB Walnut : AMCC 405GP 200 MHz 100 MHz 16 KB8 kB 32 MB Yosemite: AMCC 440EP 533 MHz 133 MHz 32 KB 32 KB 256 MB DDR-RAM, FPU Ocotea : AMCC 440GX 533 MHz 152 MHz 32 KB 32 KB 256 MB DDR-RAM, L2 256 KB Linux : DENX linux-2.6.14-rc3-g4c234921 iPipe : 1.0-00 Xenomai: SVN 2005-10-15 CRUNCER without load: | Ideal computation time TQM860L | 368 us ??? TQM866L | 10008 us Walnut | 10150 us Yosemite | 9911 us Ocotea | 9479 us SWITCH without load: | lat min| lat avg| lat max|lost TQM860L | 103360| 107840| 209280| 0 TQM866L | 25745| 31880| 51369| 5 Walnut | 24620| 25965| 32280| 1 Yosemite |5626|5655| 17403| 0 Ocotea |5158|5169| 10038| 0 KLATENCY with load: |-lat min|-lat avg|-lat max|-overrun|---test-time TQM860L | 50560| 98976| 199040| 0|00:09:45 TQM866L | 13835| 28571| 74348| 0|00:11:44 Walnut | 16195| 25062| 45755| 0|00:10:09 Yosemite |3106|9697| 36832| 0|00:09:55 Ocotea |3575|7438| 24474| 0|00:10:50 LATENCY with load: |-lat min|-lat avg|-lat max|-overrun|---test-time TQM860L | 60480| 120960| 224320| 0|00:09:46 TQM866L | 15759| 34286| 78799| 0|00:11:14 Walnut | 21070| 31650| 64500| 0|00:09:58 Yosemite |3808| 12163| 47898| 0|00:10:00 Ocotea |3575|7438| 24474| 0|00:10:50 KLATENCY comparison Xenomai 2.0 vs. RTAI/RTHAL 3.0r5 on TQM860L: --- KLATENCY with load: |-lat min|-lat avg|-lat max|-overrun|---test-time Xenomai 2.0 | 50560| 98976| 199040| 0|00:09:45 RTAI 3.0r5 | 23120| 31838| 70520| ?|00:12:26 Note: load has been put onto the system by running in a telnet session ping -f remote-host-ip and while ls; do ls; done. Note: all test have been run with CONFIG_XENO_HW_TIMER_LATENCY=1 and CONFIG_XENO_HW_SCHED_LATENCY=1 to get correct latancy values. RTAI figures have been corrected manually. xenomai-latencies-ppc.tgz Description: GNU Zip compressed data
Re: [Xenomai-core] Xenomai latency tests on various PowerPC boards
On 10/18/2005 01:44 PM Philippe Gerum wrote: Philippe Gerum wrote: Wolfgang Grandegger wrote: Hallo, attached you will find the results of Xemonai latency measurements on various embedded PowerPC boards using MPC 8xx and AMCC 4xx processors, from low to high end covering a worst case latency range from 25 to 225 us. It also includes a comparison with RTAI 3.0r5 on the slowest CPU. Here are some remarks and comments: - On low-end processor code size matters a lot and it's difficult to beat RTAI/RTHAL. Beat no, get closer, yes, probably. The good news is that looking at the figures, we do have a margin of improvement! :o Btw, the nucleus can be configured so that the user-space threading engine is compiled out (i.e. CONFIG_XENO_OPT_PERVASIVE from the nucleus menu), which would be the corresponding profile to compare with klatency (i.e. sched_up). Disabling this option reduces the code size for the nucleus from: text databssdechexfilename 66740792 6540 74072 12158 nucleus/xeno_nucleus.ko to: text databssdechexfilename 52596576 3956 57128 df28 nucleus/xeno_nucleus.ko Disabling the periodic timer support which is unused for the klatency test brings this down to: text data bss dec hex filename 51040 5443956 55540d8f4 nucleus/xeno_nucleus.ko OK, here are the new figures with (*) CONFIG_XENO_OPT_PERVASIVE is not set CONFIG_XENO_HW_PERIODIC_TIMER is not set: |-lat min|-lat avg|-lat max|-overrun|---test-time RTAI 3.0r5 | 23120| 31838| 70520| ?|00:12:26 Xenomai| 50560| 98976| 199040| 0|00:09:45 Xenomai (*)| 44160| 96215| 200640| 0|00:09:53 The min latency decreases as expected. Still a bit fat though. - Apart from the CPU power, big caches and a fast memory interface improves latencies. - L2 cache improves latencies a lot (compare Ocotea with Yosemite). - I'm a bit puzzled about the results of the cruncher test. Could someone explain the output, please? This test is reminiscent of the HYADES project (ia64 port of RTAI/fusion), where we wanted to illustrate the level of execution determinism one could achieve using the interrupt shield technique on large ia64 SMP systems. To this end, we measured the jitter in execution time of a calibrated float-crunching loop, with and without interrupt load. This test is likely going to disappear at some point in time, because it's not that informative in Xeno's context. - Stability seems already quite good. At least I did not observe any crash yet :-). That's cool. I see no other way to properly improve performances than first having something which could be run on various platforms without them randomly jumping out of the window, or us relying on plain Voodoo stuff to explain why those setup would work or not. The PowerPC port of Xenomai is already in good shape. That's great! Thanks. This is likely because I do feel better since I have been aware that there's life beyond x86. :o) Wolfgang. Latency tests with Xenomai on various PowerPC boards Board : Processor CPU-Clk Bus-Clk I-Cache D-Cache Memory Remarks TQM860L : MPC 860 50 MHz 50 MHz4 KB4 kB 16 MB TQM866M : MPC 866133 MHz 66 MHz 16 KB8 kB 128 MB Walnut : AMCC 405GP 200 MHz 100 MHz 16 KB8 kB 32 MB Yosemite: AMCC 440EP 533 MHz 133 MHz 32 KB 32 KB 256 MB DDR-RAM, FPU Ocotea : AMCC 440GX 533 MHz 152 MHz 32 KB 32 KB 256 MB DDR-RAM, L2 256 KB Linux : DENX linux-2.6.14-rc3-g4c234921 iPipe : 1.0-00 Xenomai: SVN 2005-10-15 CRUNCER without load: | Ideal computation time TQM860L | 368 us ??? TQM866L | 10008 us Walnut | 10150 us Yosemite | 9911 us Ocotea | 9479 us SWITCH without load: | lat min| lat avg| lat max|lost TQM860L | 103360| 107840| 209280| 0 TQM866L | 25745| 31880| 51369| 5 Walnut | 24620| 25965| 32280| 1 Yosemite |5626|5655| 17403| 0 Ocotea |5158|5169| 10038| 0 KLATENCY with load: |-lat min|-lat avg|-lat max|-overrun|---test-time TQM860L | 50560| 98976| 199040| 0|00:09:45 TQM866L | 13835| 28571| 74348| 0|00:11:44 Walnut | 16195| 25062| 45755| 0|00:10:09 Yosemite |3106|9697| 36832| 0|00:09:55 Ocotea |3575|7438| 24474| 0|00:10:50
Re: [Xenomai-core] Testing the adeos-ipipe-2.6.13-ppc-1.0-00.patch
On 10/17/2005 05:42 PM Fillod Stephane wrote: Hi Philippe, Sorry for the late report, Xenomai appears to work fine on a Freescale e500 board (MPC8541E) under Linux 2.6.13. Xenomai version was v1.9.9, ie. the daily snapshot as of today. Here are some preliminary figures (CPU 800MHz, Bus 133MHz, 32 kiB I-Cache 32 kiB D-Cache, 256 kiB L2): switch $ ./run == Sampling period: 100 us RTH| lat min| lat avg| lat max|lost RTD|3660|3690|8070| 0 kaltency $ ./run RTH|klat min|klat avg|klat max| overrun| RTS| -7350| -5715|6420| 0| 00:03:17/00:03:17 latency $ ./run == Sampling period: 100 us RTT| 00:08:04 RTH|-lat min|-lat avg|-lat max|-overrun| RTS| -6930| -4260|8700| 0| 00:08:06/00:08:06 Load for klatency/latency was ping flooding on FCC (piece of cake), and cache calibrator. IMHO, we can do nastier. You mean the cache calibrator from http://monetdb.cwi.nl/Calibrator/? I tried it on my Ocotea board and it increased the max latency for 25 to 30 us. Thanks. Wolfgang.
[Xenomai-core] TLB misses on MPC 8xx
Hello, the output of the cache calibrator indicated, that TLB misses on the MPC 860 might influence latencies substantially. Looking closer to the Linux 2.6 kernel revealed, that TLB entries for the kernel space (0xc000) are not pinned by default for the MPC 860 (like in 2.4). I enabled this advanced kernel option PIN_TLB and furthermore patched the kernel to put modules in that kernel space by using kmalloc instead of vmalloc. Then I get the following latency figures: KLATENCY with load: RTH|---lat min|---lat avg|---lat max|-overrun|--lat best|---lat worst RTS| 50560| 98976|199040| 0| 00:09:45 RTS| 50240| 89401|174400| 0| 00:10:06 PIN_TLB RTS| 48960| 85562|164480| 0| 00:10:30 PIN_TLB+kmalloc LATENCY with load: RTH|---lat min|---lat avg|---lat max|-overrun|--lat best|---lat worst RTS| 60480|120960|224320| 0| 00:09:46 RTS| 60800|105600|193600| 0| 00:09:56 PIN_TLB RTS| 55680| 98240|176640| 0| 00:15:01 PIN_TLB+kmalloc This clearly shows, that TLB misses are one latency killer on low end processors. Wolfgang.
Re: [Xenomai-core] Proposal to use buildbot for Xenomai
Jan Kiszka wrote: Niklaus Giger wrote: Am Samstag, 8. April 2006 10:44 schrieb Jan Kiszka: Niklaus Giger wrote: Hi everybody .. This is a really great idea! Of course, I already have another test candidate in mind: RTnet 8). Specifically the PPC environment would be interesting, as our buildbot (sorry, Wolfgang G. ;) ) is typically very busy so that build regressions are sometimes only detected with delay on that platform. Is it also possible to explicitly trigger an update and rebuild? Yes of course. Just select a buildslave (e.g. ppc or hcu3 - http://ngiger.dyndns.org/buildbot/hcu3) and you may manually trigger it. I intentionally left this facility open for everybody to test it. But it would of course be possible to restrict it only to a few selected developers. If you want, I can help you to setup the master.cfg for a rtnet buildbot. I would love to, but you know - time... But also for Xenomai I would see this as a very useful tool, e.g. for 2.4 build tests (I must confess I only test sporadically against this kernel). I will add one. Could you please e-mail me (privately if you want) a working config (ppc, no cross compiling if possible). Or do you want to add a build slave under your control? Hmm, I would prefer to just use something, especially as my PPC experiences are quite limited :). But I guess here are qualified people listening who can quickly dig out some config. In arch/ppc/configs of the (DENX) 2.4 kernel are plenty of configurations for the PowerPC boards, e.g. TQM8620_defconfig, icecube_5200_defconfig, TQM866M_defconfig, etc. But we need cross compilation for most of the embedded boards. Do you need the configuration with IPIPE and Xenomai options enabled? .. Is there no reset button you could control via a master station, e.g. by attaching some cheap electronic to a parallel or serial port? There is a reset button, but then you have it running and consuming electricity all the times. Yep, understandable. I just remember that DENX once had or still have a remote PPC test-lab running. I CC'ed Wolfgang, maybe he could comment on this if and how it could be used. I would be willing to setup a buildbot for the u-boot, too, as my board boots with a very outdated version of u-boot. We simply use remote controllable power switches to switch the boards on and off. Wolfgang. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] BuildBot progress for sim, tqm860 with RTnet
Niklaus Giger wrote: Hi I was busy improving the buildbot setup and achieved the following: - added build slave for simulator - added a buildbot for a TQM860L with Denx PPC 2.4 kernel. Cannot yet build the RTnet code. - patched buildbot to show names for shell build steps instead of the commands - Hacked buildbot to improve the displayed names of the build step (e.g. configure_xenomai instead of configure 2. I will look at Philippe's idea about collecting xenomai statistics later, because it demands more time and effort to implement. The following details are probably only of interest for people interested in TQM860 and/or RTnet. My setup for the TQM860 was the following: - Got Dan Kegel crosstool 0.42 - Compiled/installed the demo-ppc860 (gcc-3.4.1-glibc-2.3.3) - Used linuxppc_2_4_devel-2006-04-06-1735.tar.bz whith a TQM860L_defconfig plus XENOMAI extensions - Got RTnet trunk via SVN Could the interested parties please comment, whether this is a good combination or whether they prefer something different? If you follow the logs you are able to see each step and configuration option (except building the crosstool). Looks good. configure rtnet fails with the following message: checking for RT-extension... /home/buildslave/bin/linuxppc_2_4_devel-2006-04-06-1735 (Xenomai 2.0.x) checking for Xenomai version... configure: error: *** Unsupported Xenomai version 2.1.50 in /home/buildslave/bin/linuxppc_2_4_devel-2006-04-06-1735 Is the error correct? Or should I build only against Xenomai 2.0? For Xenomai 2.1.x I configure, build and install RTnet as shown: $ export CROSS_COMPILE=ppc_8xx- $ ./configure --with-linux=/temp/rt/test/linuxppc_2_4_devel-2006_03_26_1343 --host=ppc-linux --prefix=/root/xeno4rtnet --enable-fec-enet --enable-scc-enet $ make $ export DESTDIR=/opt/eldk/ppc_8xx $ make install Wolfgang. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] UVM build error in todays head of SVN
Hello, I just checked out Xenomai and realized the UVM build error below (while building for PPC 405 with IPIPE tracer). xnlock_put/get seems not to be dummy without SMP. Wolfgang. if ppc-linux-gcc -DHAVE_CONFIG_H -I. -I. -I../../../../src/include -O2 -D_GNU_SOURCE -D_REENTRANT -D__XENO__ -Wall -pipe -D__IN_XENO__ -Wstrict-prototypes -I../../../../include -D__XENO_UVM__-MT pod.o -MD -MP -MF .deps/pod.Tpo -c -o pod.o pod.c; \ then mv -f .deps/pod.Tpo .deps/pod.Po; else rm -f .deps/pod.Tpo; exit 1; fi pod.c: In function 'xnpod_announce_tick': pod.c:3304: warning: implicit declaration of function 'xnlock_get' pod.c:3304: error: 'nklock' undeclared (first use in this function) pod.c:3304: error: (Each undeclared identifier is reported only once pod.c:3304: error: for each function it appears in.) pod.c:3365: warning: implicit declaration of function 'xnlock_put' make[4]: *** [pod.o] Error 1 make[4]: Leaving directory `/.automount/castor-vlab/root/home/wolf/rt/xenomai/src/skins/uvm/nucleus' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/.automount/castor-vlab/root/home/wolf/rt/xenomai/src/skins/uvm' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/.automount/castor-vlab/root/home/wolf/rt/xenomai/src/skins' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/.automount/castor-vlab/root/home/wolf/rt/xenomai/src' make: *** [all-recursive] Error 1 ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] I-pipe latency tracer for ppc
Philippe Gerum wrote:
As promised, the I-pipe tracer has been ported to ppc. People working on
this architecture are invited to give it a try, it's a great tool to
find out where the cycles are actually going.
Just apply the tracer patch on top of the Adeos patch bearing the same
revision number, and select the feature from the kernel configuration.
If you happen to have some issue while booting the instrumented kernel
on embedded setups (e.g. freeze after kernel decompression), try
reducing the size of the trace log (CONFIG_IPIPE_TRACE_SHIFT).
http://download.gna.org/adeos/patches/v2.6/ppc/tracer/
I gave it a try on a rather low-end PowerPC Walnut board (AMCC PowerPC
405GP, Rev. E at 200 MHz, 16 kB I-Cache 8 kB D-Cache). A nice tool,
indeed, and it works fine. I have attached the results from running the
Xenomai latency -t0 test with some load showing latencies up to 140
us. The trace seems not to show any obvious problems, I think.
Thanks.
Wolfgang.
bash-3.00# cat /proc/ipipe/version
1.3-00
bash-3.00# ./latency -p500
== Sampling period: 500 us
== Test mode: periodic user-mode task
== All results in microseconds
warming up...
...
RTH|-lat min|-lat avg|-lat max|-overrun|lat best|---lat worst
RTS| 59.020| 67.260| 138.910| 0|00:54:31/00:54:31
bash-3.00# cat /proc/ipipe/trace/max
I-pipe worst-case tracing service on 2.6.14/ipipe-1.3-00
Begin: 182095500 cycles, Trace Points: 192 (-10/+3), Length: 265 us
+- Hard IRQs ('|': locked)
|+ unused
||+--- unused
|||+-- Xenomai
+- Linux ('*': domain stalled)
| +-- Delay flag ('+': 1 us, '!': 10 us)
| |+- NMI noise ('N')
| ||
Type User Val. TimeDelay Function (Parent)
*fn -303.465 timer_interrupt+0x14 (__ipipe_do_timer+0x30)
*fn -262.430 profile_tick+0x14 (timer_interrupt+0x130)
*fn -241.865 profile_hit+0x14 (profile_tick+0x78)
*fn -221.700 update_process_times+0x14 (timer_interrupt+0x13c)
*fn -203.505 account_system_time+0x14 (update_process_times+0xac)
*fn -172.195 update_mem_hiwater+0x14 (account_system_time+0x78)
*fn -151.200 run_local_timers+0x14 (update_process_times+0xb0)
*fn -14 11.905 raise_softirq+0x14 (run_local_timers+0x30)
*fn -21.200 __ipipe_restore_root+0x14 (raise_softirq+0x84)
*fn -11.095 __ipipe_stall_root+0x14 (__ipipe_restore_root+0x34)
| *begin 0x8000 0+ 3.950 __ipipe_stall_root+0x98 (__ipipe_restore_root+0x34)
:| *fn3+ 1.500 scheduler_tick+0x14 (update_process_times+0x7c)
:| *fn5+ 4.040 sched_clock+0x14 (scheduler_tick+0x34)
:| *fn9+ 1.160 run_posix_cpu_timers+0x14 (update_process_times+0x84)
:| *fn 10+ 3.120 __ipipe_test_root+0x14 (run_posix_cpu_timers+0x44)
:| *fn 13+ 2.920 do_timer+0x14 (timer_interrupt+0x154)
:| *fn 16+ 1.500 profile_tick+0x14 (timer_interrupt+0x130)
:| *fn 18+ 1.140 profile_hit+0x14 (profile_tick+0x78)
:| *fn 19+ 1.270 update_process_times+0x14 (timer_interrupt+0x13c)
:| *fn 20+ 1.370 account_system_time+0x14 (update_process_times+0xac)
:| *fn 21+ 1.325 update_mem_hiwater+0x14 (account_system_time+0x78)
:| *fn 230.995 run_local_timers+0x14 (update_process_times+0xb0)
:| *fn 24+ 1.140 raise_softirq+0x14 (run_local_timers+0x30)
:| *fn 25+ 1.350 __ipipe_test_and_stall_root+0x14 (raise_softirq+0x30)
:| *fn 26+ 1.205 __ipipe_restore_root+0x14 (raise_softirq+0x84)
:| *fn 27+ 1.735 __ipipe_stall_root+0x14 (__ipipe_restore_root+0x34)
:| *fn 29+ 1.160 scheduler_tick+0x14 (update_process_times+0x7c)
:| *fn 30+ 1.565 sched_clock+0x14 (scheduler_tick+0x34)
:| *fn 32+ 1.285 run_posix_cpu_timers+0x14 (update_process_times+0x84)
:| *fn 33+ 1.560 __ipipe_test_root+0x14 (run_posix_cpu_timers+0x44)
:| *fn 35+ 3.075 do_timer+0x14 (timer_interrupt+0x154)
:| *fn 38+ 1.460 profile_tick+0x14 (timer_interrupt+0x130)
:| *fn 39+ 1.300 profile_hit+0x14 (profile_tick+0x78)
:| *fn 40+ 1.035 update_process_times+0x14 (timer_interrupt+0x13c)
:| *fn 41+ 1.350 account_system_time+0x14 (update_process_times+0xac)
:| *fn 43+ 1.275
Re: [Adeos-main] Re: [Xenomai-core] I-pipe latency tracer for ppc
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
Philippe Gerum wrote:
As promised, the I-pipe tracer has been ported to ppc. People working
on this architecture are invited to give it a try, it's a great tool
to find out where the cycles are actually going.
Just apply the tracer patch on top of the Adeos patch bearing the same
revision number, and select the feature from the kernel configuration.
If you happen to have some issue while booting the instrumented kernel
on embedded setups (e.g. freeze after kernel decompression), try
reducing the size of the trace log (CONFIG_IPIPE_TRACE_SHIFT).
http://download.gna.org/adeos/patches/v2.6/ppc/tracer/
I gave it a try on a rather low-end PowerPC Walnut board (AMCC PowerPC
405GP, Rev. E at 200 MHz, 16 kB I-Cache 8 kB D-Cache). A nice tool,
indeed, and it works fine. I have attached the results from running the
Xenomai latency -t0 test with some load showing latencies up to 140
us. The trace seems not to show any obvious problems, I think.
Thanks.
Wolfgang.
bash-3.00# cat /proc/ipipe/version
1.3-00
bash-3.00# ./latency -p500
== Sampling period: 500 us
== Test mode: periodic user-mode task
== All results in microseconds
warming up...
...
RTH|-lat min|-lat avg|-lat max|-overrun|lat best|---lat worst
RTS| 59.020| 67.260| 138.910| 0|00:54:31/00:54:31
bash-3.00# cat /proc/ipipe/trace/max
I-pipe worst-case tracing service on 2.6.14/ipipe-1.3-00
Begin: 182095500 cycles, Trace Points: 192 (-10/+3), Length: 265 us
+- Hard IRQs ('|': locked)
|+ unused
||+--- unused
|||+-- Xenomai
+- Linux ('*': domain stalled)
| +-- Delay flag ('+': 1 us, '!': 10 us)
| |+- NMI noise ('N')
| ||
Type User Val. TimeDelay Function (Parent)
*fn -303.465 timer_interrupt+0x14
(__ipipe_do_timer+0x30)
*fn -262.430 profile_tick+0x14
(timer_interrupt+0x130)
*fn -241.865 profile_hit+0x14 (profile_tick+0x78)
*fn -221.700 update_process_times+0x14
(timer_interrupt+0x13c)
*fn -203.505 account_system_time+0x14
(update_process_times+0xac)
*fn -172.195 update_mem_hiwater+0x14
(account_system_time+0x78)
*fn -151.200 run_local_timers+0x14
(update_process_times+0xb0)
*fn -14 11.905 raise_softirq+0x14
(run_local_timers+0x30)
*fn -21.200 __ipipe_restore_root+0x14
(raise_softirq+0x84)
*fn -11.095 __ipipe_stall_root+0x14
(__ipipe_restore_root+0x34)
| *begin 0x8000 0+ 3.950 __ipipe_stall_root+0x98
(__ipipe_restore_root+0x34)
:| *fn3+ 1.500 scheduler_tick+0x14
(update_process_times+0x7c)
:| *fn5+ 4.040 sched_clock+0x14 (scheduler_tick+0x34)
This trace covers some long stall of the root domain, not the maximum
stall of the Xenomai domain that caused the 140 us above. See the
explanation for the stall bits above.
Ah, some feed for the real experts.
Maybe the maximum irq latency tracing is broken, I haven't tested it
with latest ipipe patch revision yet. Well, that max path should not
trigger on root-domain stalls as long as there is some higher priority
domain running - and it should have been reset on xenomai mounting. Hmm,
maybe only that reset does not work, please check by running echo
/proc/ipipe/trace/max before the latency test.
Yes, that changed something. I have attached the new output listing.
You could also test if the -f option of latency works for you. You will
find the result of the back-trace freezing on max latency under
/proc/ipipe/trace/frozen. The number of back-trace points can be tuned
even after the event (only post-tracing required ahead-of-time tuning).
Seem to work. The output has been added to the attached file.
Wolfgang.
bash-3.00# cat /proc/ipipe/trace/max
I-pipe worst-case tracing service on 2.6.14/ipipe-1.3-00
Begin: 90358006525 cycles, Trace Points: 25 (-10/+4), Length: 69 us
+- Hard IRQs ('|': locked)
|+ unused
||+--- unused
|||+-- Xenomai
+- Linux ('*': domain stalled)
| +-- Delay flag ('+': 1 us, '!': 10 us)
| |+- NMI noise ('N')
| ||
Type User Val. TimeDelay Function (Parent)
fn -251.935 schedule+0x14 (syscall_exit_work+0x110)
fn -232.075 profile_hit+0x14 (schedule+0x68)
fn -212.390 sched_clock+0x14 (schedule+0xa0)
fn
Re: [Xenomai-core] RTDM driver add-on infrastructure
Jan Kiszka wrote: Wolfgang Grandegger wrote: Hello, I'm currently implementing a RTDM real-time CAN driver, which raises the the problem of adding the driver to the Xenomai source tree. My first idea was to provide RTCAN as a patch for Xenomai: So you prefer to maintain RTCAN out-of-tree on the long term? What are the reasons? No, when the code is stable it can go to the Xenomai repository, like for the Linux kernel. It clearly simplifies maintenance , at least for the maintainer of the driver. Nevertheless, an Add-On facility would be nice to have. $ cd xenomai $ patch -p1 xenomai-rtcan-add-on.patch $ scripts/prepare_kernel ... ... $ configure and make kernel $ configure, make and install Xenomai user space stuff This does not work because of autoconf files needed to copy header files to the installation path. Is this really necessary? Another issue is where to put utility and test programs. Making them without autoconf and friends works by using xeno-config. But they should be installed with make install as well. Likely there are other issues. Any ideas or comments on how to provide a generic RTDM driver add-on infrastructure? When you first talked about an RTDM plugin interface for Xenomai, I got the idea of dragging external sources into the Xenomai kernel build process. I haven't thought about this technically yet, but it would allow to keep driver source packages maintained externally while still providing them the option to become built into the kernel. Ok, let's think about this for a while: We would need some management script(s) to link an external source tree into the config and build process, the remove it again, and probably to give a list of the currently active plugins. Should be feasible without huge magic, shouldn't it? But does this make sense, is it desirable (to me it is when I think about making RTnet build cleanly against 2.6.17 yesterday...)? Ala Xenomai's prepare_kernel script, which mainly adds links to the kernel tree and modifies some Makefiles and Kconfig (Config.in) files. Removing an Add-On seems not to be that important for me. This sounds reasonable. Adding the RTCAN driver to Xenomai really solved a lot of build and installations issues without caring about the kernel version 2.4 or 2.6 :-). This does not address your user mode utils, but I think they should rather be distributed independently (something I have in mind for RTnet as well once we ever switch from /dev/rtnet to some RTDM socket/device for config work). The required rtdm/rtcan.h should be merged into Xenomai, yet unmerged revisions could alternatively come with the rtcan-utils packages to make it build (autoconf if your friend to detect the available revision). I think the Add-on package should provide both, the driver _and_ user-space utility and test programs. Wolfgang. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] prepare_kernel --output-patch
Hello, what is prepare_kernel --output-patch useful for? Thanks. Wolfgang. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] cpu_set_t and friends undefined
Hello, with todays SVN version of Xenomai, the testsuite program switchtest/switch.c does not compile because cpu_set_t and friends (CPU_SET, ...) are not undefined. I'm using kernel version 2.4.25. Any idea what goes wrong. I haven't found where cpu_set_t is declared, not even in Linux 2.4.17.7. Thanks. Wolfgang. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [ANNOUNCE] RTDM driver for CAN devices
: --- Now boot the Xenomai enabled kernel on your target system. In case RTCAN is built as kernel modules, you need to load them using modprobe or insmod, e.g. for this example build: # export MODDIR=/lib/modules/2.4.25/kernel/drivers/xenomai/rtcan # insmod $MODDIR/xeno_rtcan.o # insmod $MODDIR/mscan/xeno_rtcan_mscan.o # insmod $MODDIR/sja1000/xeno_rtcan_sja1000.o # insmod $MODDIR/sja1000/xeno_rtcan_peak_pci.o Note that various kernel module parameters can be passed with insmod. Please use modinfo to list them or check the corresponding source code files for further information There are a few RTCAN utilities to configure RTCAN and to send and receive CAN messages, which have been installed in the Xenomai installation directory with make install: # export XENO_ROOT=/usr/xenomai # export PATH=$PATH:$XENO_ROOT/bin # export LD_LIBRARY_PATH=$XENO_ROOT/lib # rtcanconfig --help Usage: rtcanconfig can-interface [Options] [up|down|start|stop|sleep] Options: -v, --verbosebe verbose -h, --help this help -c, --ctrlmode=M1:M2:... listenonly or loopback mode -b, --baudrate=BPS baudrate in bits/sec -B, --bittime=BTR0:BTR1 BTR or standard bit-time -B, --bittime=BRP:PROP_SEG:PHASE_SEG1:PHASE_SEG2:SJW:SAM # rtcanrecv --help Usage: rtcanrecv can-interface [Options] Options: -f --filter=id:mask[:id:mask]... apply filter -e --error=mask receive error messages -t, --timeout=MS timeout in ms -v, --verbose be verbose -p, --print=MODULOprint every MODULO message -n, --name=STRING name of the RT task -h, --helpthis help # rtcansend --help Usage: rtcansend can-interface [Options] can-msg can-msg can consist of up to 8 bytes given as a space separated list Options: -i, --identifier=ID CAN Identifier (default = 1) -r --rtr send remote request -e --extendedsend extended frame -l --loop=COUNT send message COUNT times -c, --count message count in data[0-3] -d, --delay=MSdelay in ms (default = 1ms) -t, --timeout=MS timeout in ms -v, --verbose be verbose -p, --print=MODULOprint every MODULO message -h, --helpthis help Here are a few self-explanary commands: # rtcanconfig rtcan0 --baudrate=125000 start # rtcansend rtcan2 --verbose --identifier=0x123 0xde 0xad 0x123 [2] de ad # rtcanrecv rtcan0 --verbose #1: 0x123 [2] de ad bash-2.05b# rtcanrecv rtcan0 --filter=0x120:0x120 Filter #0: id=0x0120 mask=0x0120 #0: 0x124 [2] de ad #1: 0x123 [3] 12 34 56 #2: 0x133 [4] 11 22 33 44 # rtcanrecv rtcan0 --error=0x #1: !0x0008! [8] 00 00 80 19 00 00 00 00 ERROR PROC filesystem: the followingfiles provide useful information on the status of the CAN controller, filter settings, registers, etc. # cat /proc/rtcan/devices Name___ _Baudrate State___ TX_Counter RX_Counter Errors rtcan0 125000 active0 8 0 rtcan1 125000 active0 8 0 rtcan2 125000 passive 8 0 14714 # cat /proc/rtcan/sockets fd Name___ Filter ErrMask RX_Timeout_ns TX_Timeout_ns RX_BufFull 0 rtcan0 1 0x0 infinite infinite 0 1 rtcan0 1 0x0 infinite infinite 0 # cat /proc/rtcan/rtcan2/info Device rtcan2 Controller SJA1000 Board PEAK-PCI Clock-Hz 800 Baudrate 125000 Bit-time brp=4 prop_seg=0 phase_seg1=13 phase_seg2=2 sjw=1 sam=0 Ctrl-Mode State passive TX-Counter 3 RX-Counter 0 Errors 45424 Refcount 0 # cat /proc/rtcan/rtcan0/filters fd __CAN_ID__ _CAN_Mask_ MatchCount 0 0x 0x 0 1 0x0120 0x0120 3 # cat /proc/rtcan/rtcan0/registers MSCAN registers at f900 canctl0 0x90 rxfrm synch canctl1 0xc0 cane clksrc ... # cat /proc/rtcan/rtcan2/registers SJA1000 registers 00: 00 00 4c 00 ff 00 03 1c 1a 00 00 02 d6 60 14 88 10: 02 26 60 de ad 04 04 00 ef c7 ef ef 40 00 00 c7 Documentation: - Temoporarily, The RTDM CAN profile is documented using Doxygen in api_doc/index.html Feedback: Please report Xenomai related bugs and comments to the Xenomai mailing list xenomai-help@gna.org. Please report CAN related bugs and comments to the Socketcan mailing list ([EMAIL PROTECTED]) or directly to the main authors Wolfgang Grandegger ([EMAIL PROTECTED]) or Sebastian Smolorz ([EMAIL PROTECTED]). Credits: --- See CREDITS file. License: --- RTCAN is free software, and you are welcome to redistribute it under the terms of the GNU General Public License. This program comes with ABSOLUTELY NO WARRANTY. See COPYING for details. ___ Xenomai-core mailing
Re: [Xenomai-core] Future of Xenomai's RTDM driver repository
Jan Kiszka wrote: Hi, instead of replying directly to Wolfgang's announcement of their great CAN stack I take the chance to start a generic thread on the future of RTDM drivers *within* Xenomai. If you look at the real-time Linux scene now and in the past, you may find it fairly scattered. Specifically precious Open Source drivers are hard to find, not always up-to-date, or not ported to your favourite kernel/RT-patch. Just check how many CAN driver projects for how many RT APIs are out there. There are even a few hardware vendors providing driver packages for real-time Linux, others offer at least some kind of reference code, but many nothing at all. Sad but true for _many_ years. RTDM came into play to provide a common ground for real-time driver development under Linux. It is already utilised by quite a few stand-alone driver projects and even vendor drivers. But as resources are limited, maintenance is tricky, and testers are rare, we should consider concentrating driver development efforts more intensively. I'm convinced such concentration should primarily happen within the Xenomai driver repository. Xenomai has the unique potential to provide a real-time framework for both the co-scheduling approach and for the native RT-Linux environment that Preempt-RT will probably push into mainline one day. And Xenomai is also a sound foundation for the tricky 2.4/2.6 support scenario. Here are the concrete advantages I see in maintaining drivers *inside* Xenomai: o Better visibility (did you know that there is a working FireWire stack for Xenomai?) o Better testing, also across architectures, due to more users (this applies to the drivers, but also to RTDM and Xenomai in all) o Closer to the latest RTDM development o Wrapping environments for changing kernel interfaces (2.4/2.6 etc.) o In-kernel build o Simpler build system (look at RTnet...) o Single, integrated package, thus less breakages due to version mismatches Of course, there are also certain critical topics that need to be resolved first: o Clear acceptance rules - Maintenance commitment: dump-and-run will not scale. Unless there is already a community behind it, complex drivers need people to look after them. Dead/unused drivers should get moved in some corner after a while. - Coding style: Should simply be kernel style (though I personally hate tabs). - Documentation: New RTDM profiles as well as the drivers themselves must contain some words (surely a more softish requirement). - Test cases, test conformance: Drivers should provide some simple tests or, if once available, conform to existing tests for their RTDM profiles. o Repository organisation - Where to keep utilities (Wolfgang raised this as well)? Should a rtcanconfig come with Xenomai, as a separate package of rt-utils, or as package of its own? - Where to put test cases? Distribute them separately? - Where to collect usage examples? This is actually a generic question, also for the skins (I think the current situation is a bit unsatisfactory). o Support organisation Simple drivers can certainly be managed via xenomai-help, existing communities will continue to use their own forums, but what about new subsystems? I could imagine introducing some [EMAIL PROTECTED] lists for them, Philippe suggested simply xenomai-drivers which is likely already sufficient. Now I would suggest to look at RTCAN (or what it will be called in the end) and to discuss on this first concrete example how we can proceed towards the sketched goal. Looking forward to your feedback! As you have said, maintaining a RTDM driver within the Xenomai repository clearly has some advantages but it also puts more burden onto the Xenomai maintainers and some developers might even prefer to keep thing separated. Therefore I suggest a simple RTDM add-on framework to support external RTDM drivers as well. They could be announced and listed on the Xenomai home page and then it would alsl be visible that there is a FireWire stack for Xenomai. What I had first was a add-rtdm-driver.sh, a modified version of Philippe's prepare-kernel.sh script, to add the RTDM driver to the kernel tree. Similarly, as script could be used to add loosely the driver to Xenomai. What do you think? Wolfgang. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Future of Xenomai's RTDM driver repository
Philippe Gerum wrote: Hi Wolfgang, First of all, thx for the CAN stack. Great job. On Thu, 2006-08-03 at 09:58 +0200, Wolfgang Grandegger wrote: Jan Kiszka wrote: snip Now I would suggest to look at RTCAN (or what it will be called in the end) and to discuss on this first concrete example how we can proceed towards the sketched goal. Looking forward to your feedback! As you have said, maintaining a RTDM driver within the Xenomai repository clearly has some advantages but it also puts more burden onto the Xenomai maintainers and some developers might even prefer to keep thing separated. Therefore I suggest a simple RTDM add-on framework to support external RTDM drivers as well. They could be announced and listed on the Xenomai home page and then it would alsl be visible that there is a FireWire stack for Xenomai. What I had first was a add-rtdm-driver.sh, a modified version of Philippe's prepare-kernel.sh script, to add the RTDM driver to the kernel tree. Similarly, as script could be used to add loosely the driver to Xenomai. What do you think? I can't speak for Jan wrt providing a RTDM add-on framework, but since Xenomai is currently the reference platform for RTDM (at least, the real-time infrastructure over which most of this work is experimented, debugged and stabilized), I would rather seek integration of RTDM-based drivers into the Xenomai tree, instead of a complete separation. I understood that Jan also prefers driver integration into Xenomai. Just for some big external package like RTnet, an add-on would be nice to benefit from the Xenomai infrastructure (static linking, etc.). The reason being that it makes sense (to a Xenomai maintainer, that is) to reduce the odds of discrepancies between the core real-time framework, the driver infrastructure and the client drivers, at least while the first two are undergoing a rapid evolution. The same in-tree vs out-of-tree drivers maintenance dilema which is known from the kernel folks will also apply to us, if RTDM, and/or RTDM over Xenomai are as successful as we wish, i.e. creating opportunities to provide lots of RT drivers sharing a common infrastructure. Said differently, the day a significant number of people will start relying on a rich collection of RTDM-based drivers over Xenomai, we _will_ have maintenance issues to deal with, anyway, starting with answering a lot of questions on xenomai-whatever*. In such a case, I'd rather reduce the odds of integration issues between Xenomai-RTDM and/or RTDM/drivers. This said, I'm not saying that Xenomai should be the only RTDM-based driver repository in the long run; but I'm arguing that Xenomai could be used as a centripetal force to help developing and stabilizing the RT driver ecosystem around RTDM. OK, I can follow your arguments. It's fine for me. Thanks. Wolfgang. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Re: [Xenomai-help] [ANNOUNCE] RTDM driver for CAN devices
Jan Kiszka wrote:
Hi Wolfgang,
Wolfgang Grandegger wrote:
Hello,
at ftp://ftp.denx.de/pub/xenomai/rtcan; you can find a first version of
RTCAN, an Open Source hard real-time protocol stack for CAN devices
based on BSD sockets. It is based on the SJA1000 socket-based CAN driver
for RTDM by Sebastian Smolorz (see CREDITS file).
I started a review of the patch, and here are some first results. A
deeper look into critical paths is pending. But given that your
driver(s) already proved to work fine for us here and for your own
scenarios, only very sneaking issues can persist - if at all. :)
Puh, still plenty of issues. I wanted to make RTCAN public a.s.a.p.
because a few people already ask for it.
- AF_CAN is still set to 30 which meanwhile became TIPC. The Socket-CAN
project moved to 29 now. However, this could become a nice race until
Socket-CAN is upstream and reserved a final ID. How to cope with this?
We just had some fun here after moving our AF_TIMS from 0 to 27,
breaking many installation on our robots due to the ABI change. Should
we better move the ID beyond AF_MAX for now? Also a question for the
socketcan-core list...
For the time being I fixed it to 29.
- Out-commented debug messages: If they can be useful for driver
development / hardware testing, I would say make them selectable via
some CONFIG-switch. The rest should be removed.
OK, I'm going to implement a general debug option selectable via
kernel parameter and proc filesystem during run time some time later.
- rtcan_mscan_mode_stop() contains some #if 1-#else-#endif block. What
are the alternatives here? Is it an open issue or just a pending cleanup?
- rtcan_mscan_init_one() contains a #ifdef FIXME. What needs to be
fixed? Comments for non-obvious pending issues would be helpful.
There are a few open issues with the MSCAN hardware, especially entering
sleep mode (it does not work as expected/documented). I will cleanup anyhow.
- Can rtcan_mscan_exit() be tagged with __exit?
Of course, fixed.
- Is rtcan_mscan_proc_regs() a kind of debug option or useful for normal
operation as well? If it's the former, we may bundle it with the debug
print CONFIG-switch.
It's only useful for development and debugging. I will enable it with
the debug option mentioned above sometime later.
- Private data alignment in rtcan_dev_alloc(): you tapped on something
that looks ugly in RTnet as well. We copied this from Linux which still
does magic 32-byte alignment (encapsulated by NETDEV_ALIGN today). But
it also uses a smarter priv lookup now:
#define NETDEV_ALIGN32
#define NETDEV_ALIGN_CONST (NETDEV_ALIGN - 1)
static inline void *netdev_priv(struct net_device *dev)
{
return (char *)dev + ((sizeof(struct net_device)
+ NETDEV_ALIGN_CONST)
~NETDEV_ALIGN_CONST);
}
Maybe something that should be adopted as well (for both stacks).
Nothing critical though.
I removed alignment because I think it's better to have all data close
together. What's the benefit of such an alignment. Note that the priv
structures are normally small.
- rtcan_dev_unregister() looks racy: down(rtcan_devices_nrt_lock) comes
after the device state check. Is this ok?
That's copied from rtdev.c. Indeed, it should be:
RTCAN_ASSERT(atomic_read(dev-refcount) == 0,
printk(RTCAN: dev reference counter 0!\n););
rtdm_lock_put_irqrestore(rtcan_devices_rt_lock, context);
up(rtcan_devices_nrt_lock);
- EXPORT_SYMBOL vs. EXPORT_SYMBOL_GPL: For me this makes no practical
difference anymore (kernel modules, specifically drivers must be GPL, no
matter what kind of symbols they use). Anyway, shouldn't we better go
the kernel path and introduce new APIs under _GPL? Just takes a wrapper
for 2.4 I guess.
Fine for me. Other comments?
- struct rtcan_device: what the heck are max_brp and max_sjw
(comments...)? This isn't something generic, right? That's why FIXME I
guess.
These variables might be necessary for some other CAN controllers to
calculate the bit-timing parameters. Anyhow, I will remove them as long
as they are not needed.
- LIST_POISON1 and some other stuff in rtcan_internal.h should
definitely be moved to the nucleus's wrapper. Nothing critical, just a
to-do. Likely the whole header will be obsolete in the end.
OK.
- [This is a note for me] RTCAN_ASSERT: Looks like we should introduce
RTDM_ASSERT() for this, maybe accepting some driver subsystem ID to
control this separately from the rest of Xenomai.
Fine for me. Let me know when it will be available.
- RTCAN_PROC_... requires some thoughts: Generalise it? Some users
(haven't checked RTCAN for this, but RTnet has some) should better be
converted to seq_operations. And the rest could benefit from a generic
interface here. Uncritical for now.
OK, I will leave it for the moment.
- rtcan_dev_get_state_name(): Mm, having some array lookup for the name
here may
[Xenomai-core] Re: [Xenomai-help] [ANNOUNCE] RTDM driver for CAN devices
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
Jan Kiszka wrote:
Hi Wolfgang,
Wolfgang Grandegger wrote:
Hello,
at ftp://ftp.denx.de/pub/xenomai/rtcan; you can find a first version of
RTCAN, an Open Source hard real-time protocol stack for CAN devices
based on BSD sockets. It is based on the SJA1000 socket-based CAN driver
for RTDM by Sebastian Smolorz (see CREDITS file).
I started a review of the patch, and here are some first results. A
deeper look into critical paths is pending. But given that your
driver(s) already proved to work fine for us here and for your own
scenarios, only very sneaking issues can persist - if at all. :)
Puh, still plenty of issues. I wanted to make RTCAN public a.s.a.p.
because a few people already ask for it.
Most of my points are either small changes or just notes for future
cleanups, i.e. no show stoppers. The name, that one is critical.
See below.
- AF_CAN is still set to 30 which meanwhile became TIPC. The Socket-CAN
project moved to 29 now. However, this could become a nice race until
Socket-CAN is upstream and reserved a final ID. How to cope with this?
We just had some fun here after moving our AF_TIMS from 0 to 27,
breaking many installation on our robots due to the ABI change. Should
we better move the ID beyond AF_MAX for now? Also a question for the
socketcan-core list...
For the time being I fixed it to 29.
Ok.
- Out-commented debug messages: If they can be useful for driver
development / hardware testing, I would say make them selectable via
some CONFIG-switch. The rest should be removed.
OK, I'm going to implement a general debug option selectable via
kernel parameter and proc filesystem during run time some time later.
Fine with me, but I would skip the work for a /proc switch.
There will be no separate switch for the PROC output. I was thinking
about one global debug option.
- Private data alignment in rtcan_dev_alloc(): you tapped on something
that looks ugly in RTnet as well. We copied this from Linux which still
does magic 32-byte alignment (encapsulated by NETDEV_ALIGN today). But
it also uses a smarter priv lookup now:
#define NETDEV_ALIGN32
#define NETDEV_ALIGN_CONST (NETDEV_ALIGN - 1)
static inline void *netdev_priv(struct net_device *dev)
{
return (char *)dev + ((sizeof(struct net_device)
+ NETDEV_ALIGN_CONST)
~NETDEV_ALIGN_CONST);
}
Maybe something that should be adopted as well (for both stacks).
Nothing critical though.
I removed alignment because I think it's better to have all data close
together. What's the benefit of such an alignment. Note that the priv
structures are normally small.
This needs a closer look indeed. We adopted what Linux does without
checking if it makes sense for RTnet. The CAN devices' private data
structures are different from RT-NICs, so a different alignment may make
sense as well. Let's keep it as it is and push it on the to-do list.
IMHO, the alignment makes sense, if the private structure is used in a
different context. This is not true for RTCAN. I will put it to the TODO
list.
- rtcan_dev_unregister() looks racy: down(rtcan_devices_nrt_lock) comes
after the device state check. Is this ok?
That's copied from rtdev.c. Indeed, it should be:
RTCAN_ASSERT(atomic_read(dev-refcount) == 0,
printk(RTCAN: dev reference counter 0!\n););
rtdm_lock_put_irqrestore(rtcan_devices_rt_lock, context);
up(rtcan_devices_nrt_lock);
Argh, that locking is indeed like RTnet. And it makes me sick though I'm
likely responsible for most of this mess, thus also for this confusion
here. Please revert it for now until I sorted things in RTnet. The
locking must be simplified - and documented...
OK.
In any case, we may only suffer from theoretical races between
rtcanconfig and rmmod here. Uncritical.
Dito.
- struct rtcan_rb_frame differs from struct can_frame in the type of
can_dlc. The VW guys find __u8 for this nicer than a natural unsigned
int, but I stopped arguing on this. If we follow or not, it should be
consistent.
I don't like the __u8 either. What do you mean with the last sentence?
What should be consistent?
The types for can_dlc in both of our own structures. If can_frame uses
unsigned int, rtcan_rb_frame should do so as well.
Ah, of course, will fix that.
- Well known issue: the RTCAN name. This should definitely get resolved
before we merge. Any feedback already?
I contacted the author. If I will not get an answer soon, I tend
changing the global name to RT-Socket-CAN (rtsocketcan).
I would really hate to have a drivers/rtsocketcan or a
rtdm/rtsocketcan.h. The short name is so much nicer.
He did not say, that we cannot use the name RTCAN but he prefers that we
use a different name to avoid confusion. Therefore I suggest to use the
offical name RT-Socket-CAN for the project, but leave almost all
internal rtcan prefixes as they are apart from
[Xenomai-core] Re: [Xenomai-help] [ANNOUNCE] RTDM driver for CAN devices
Jan Kiszka wrote: Wolfgang Grandegger wrote: - Well known issue: the RTCAN name. This should definitely get resolved before we merge. Any feedback already? I contacted the author. If I will not get an answer soon, I tend changing the global name to RT-Socket-CAN (rtsocketcan). I would really hate to have a drivers/rtsocketcan or a rtdm/rtsocketcan.h. The short name is so much nicer. He did not say, that we cannot use the name RTCAN but he prefers that we use a different name to avoid confusion. Therefore I suggest to use the offical name RT-Socket-CAN for the project, but leave almost all internal rtcan prefixes as they are apart from: drivers/rtsocketcan rtdm/rtsocketcan.h Note that the API does use the Linux naming in most cases (with the prefix can). Another possibility would be to use rtscan as short form for rtsocketcan as prefix. What do you think? Well, it's just a name. Never underestimate naming. Ok, I have this proposal now: o drivers/can/ - That's consistent with the existing subdir naming anyway. I was also thinking about that. o rtdm/rtcan.h - The rtdm/ prefix clearly defines the context: It's THE standard real-time CAN profile for RTDM. o All references to RTCAN in comments, READMEs, headers, etc. must be changed to RT-Socket-CAN. So it should be clear that this has nothing to do with the existing rtcan project. o Variable, type, and function names remain as they are. OK, thats fine for me. The important thing is, that the official project name is different from RTCAN. Jan PS: Another point for the long-term to-do list :- : The nested locking and the global scope of certain locks. It's safe, it's harmless for current primary target platforms (UP), but it's not really beautiful when considering SMP setups. A bit tricky, for sure. Yes, it's also not nice, that it is in the HW specific driver. I did not touch it because I have no SMP system for testing. Wolfgang. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Re: [Xenomai-help] [ANNOUNCE] RTDM driver for CAN devices
Jan Kiszka wrote: Wolfgang Grandegger wrote: - Well known issue: the RTCAN name. This should definitely get resolved before we merge. Any feedback already? I contacted the author. If I will not get an answer soon, I tend changing the global name to RT-Socket-CAN (rtsocketcan). I would really hate to have a drivers/rtsocketcan or a rtdm/rtsocketcan.h. The short name is so much nicer. He did not say, that we cannot use the name RTCAN but he prefers that we use a different name to avoid confusion. Therefore I suggest to use the offical name RT-Socket-CAN for the project, but leave almost all internal rtcan prefixes as they are apart from: drivers/rtsocketcan rtdm/rtsocketcan.h Note that the API does use the Linux naming in most cases (with the prefix can). Another possibility would be to use rtscan as short form for rtsocketcan as prefix. What do you think? Well, it's just a name. Never underestimate naming. Ok, I have this proposal now: o drivers/can/ - That's consistent with the existing subdir naming anyway. o rtdm/rtcan.h - The rtdm/ prefix clearly defines the context: It's THE standard real-time CAN profile for RTDM. o All references to RTCAN in comments, READMEs, headers, etc. must be changed to RT-Socket-CAN. So it should be clear that this has nothing to do with the existing rtcan project. o Variable, type, and function names remain as they are. Jan PS: Another point for the long-term to-do list :- : The nested locking and the global scope of certain locks. It's safe, it's harmless for current primary target platforms (UP), but it's not really beautiful when considering SMP setups. A bit tricky, for sure. I just realized another issue. Where to put README and CREDITS file? The README should go into doc/txt/can-driver.txt. Should I add the credits to this file as well? Wolfgang. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Re: [PATCH] add virtual CAN bus driver
Hi Jan, Jan Kiszka wrote: For review: Here comes a tiny but fairly useful new CAN driver: a virtual CAN bus consisting of 2..n devices (see module parameter). Transmission takes places from the sender to all other devices on the bus, just like in real life. This driver was already helpful for me while adapting CanFestival, a LGPL CANopen library, to our CAN API -- inside qemu, i.e. without any real hardware around. I have tested it on my setup (MPC5200 with MSCAN and PEAK-PCI card under Linux 2.4) and it works fine. Wolfgang. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Re: [PATCH] refactor and enhance rtcanrecv/send
Hi Jan,
Jan Kiszka wrote:
For review:
This patch folds the rt-threads of rtcanrecv/send into the main thread,
assigns unique thread names, and lowers the priorities to some less
critical level. Furthermore, rtcanrecv is enhanced by a printout of the
CAN device and support for listening on all interfaces. On reception of
RTR frames, no more data is printing now. I also kicked out the
rt_timer_set_mode call, please speak up if it was there for a reason.
Looks good and still works. I was also thinking to use recvmsg in
rtcanrecv to show timestamps on request. Will provide a patch sooner
than later.
Wolfgang.
Jan
Index: src/utils/can/rtcansend.c
===
--- src/utils/can/rtcansend.c (Revision 1525)
+++ src/utils/can/rtcansend.c (Arbeitskopie)
@@ -69,7 +69,7 @@ void cleanup_and_exit(int sig)
exit(0);
}
-void rt_task(void *arg)
+void rt_task(void)
{
int i, j, ret;
@@ -107,7 +107,6 @@ void rt_task(void *arg)
printf(\n);
}
}
-loops = 0;
}
int main(int argc, char **argv)
@@ -115,6 +114,7 @@ int main(int argc, char **argv)
struct sockaddr_can addr;
int i, opt, ret;
struct ifreq ifr;
+char name[32];
struct option long_options[] = {
{ help, no_argument, 0, 'h' },
@@ -252,16 +252,14 @@ int main(int argc, char **argv)
}
}
- rt_timer_set_mode(TM_ONESHOT);
-
-ret = rt_task_spawn(rt_task_desc, , 0, 99, 0, rt_task, 0);
+snprintf(name, sizeof(name), rtcansend-%d, getpid());
+ret = rt_task_shadow(rt_task_desc, name, 1, 0);
if (ret) {
-fprintf(stderr, rt_task_spawn: %s\n, strerror(-ret));
+ fprintf(stderr, rt_task_shadow: %s\n, strerror(-ret));
goto failure;
}
-while (loops)
- usleep(10);
+rt_task();
cleanup();
return 0;
Index: src/utils/can/rtcanrecv.c
===
--- src/utils/can/rtcanrecv.c (Revision 1525)
+++ src/utils/can/rtcanrecv.c (Arbeitskopie)
@@ -15,14 +15,13 @@
static void print_usage(char *prg)
{
fprintf(stderr,
- Usage: %s can-interface [Options]\n
+ Usage: %s [can-interface] [Options]\n
Options:\n
-f --filter=id:mask[:id:mask]... apply filter\n
-e --error=mask receive error messages\n
-t, --timeout=MS timeout in ms\n
-v, --verbose be verbose\n
-p, --print=MODULOprint every MODULO message\n
--n, --name=STRING name of the RT task\n
-h, --helpthis help\n,
prg);
}
@@ -30,7 +29,7 @@ static void print_usage(char *prg)
extern int optind, opterr, optopt;
-static int s = -1, running = 1, verbose = 0, print = 1;
+static int s = -1, verbose = 0, print = 1;
static nanosecs_rel_t timeout = 0;
RT_TASK rt_task_desc;
@@ -75,18 +74,20 @@ void cleanup_and_exit(int sig)
{
if (verbose)
printf(Signal %d received\n, sig);
-running = 0;
cleanup();
exit(0);
}
-void rt_task(void *arg)
+void rt_task(void)
{
int i, ret, count = 0;
struct can_frame frame;
+struct sockaddr_can addr;
+socklen_t addrlen = sizeof(addr);
-while (running) {
- ret = rt_dev_recv(s, (void *)frame, sizeof(can_frame_t), 0);
+while (1) {
+ ret = rt_dev_recvfrom(s, (void *)frame, sizeof(can_frame_t), 0,
+ (struct sockaddr *)addr, addrlen);
if (ret 0) {
switch (ret) {
case -ETIMEDOUT:
@@ -100,12 +101,11 @@ void rt_task(void *arg)
default:
fprintf(stderr, rt_dev_recv: %s\n, strerror(-ret));
}
- running = 0;
break;
}
if (print (count % print) == 0) {
- printf(#%d: , count);
+ printf(#%d: (%d) , count, addr.can_ifindex);
if (frame.can_id CAN_ERR_FLAG)
printf(!0x%08x!, frame.can_id CAN_ERR_MASK);
else if (frame.can_id CAN_EFF_FLAG)
@@ -114,9 +114,10 @@ void rt_task(void *arg)
printf(0x%03x, frame.can_id CAN_SFF_MASK);
printf( [%d], frame.can_dlc);
- for (i = 0; i frame.can_dlc; i++) {
- printf( %02x, frame.data[i]);
- }
+ if (!(frame.can_id CAN_RTR_FLAG))
+ for (i = 0; i frame.can_dlc; i++) {
+ printf( %02x, frame.data[i]);
+ }
if (frame.can_id CAN_ERR_FLAG) {
printf( ERROR );
if (frame.can_id CAN_ERR_BUSOFF)
@@ -138,6 +139,7 @@ int main(int argc, char **argv)
u_int32_t err_mask = 0;
struct ifreq ifr;
char *ptr;
+char name[32];
struct option long_options[] = {
{ help, no_argument, 0, 'h' },
@@ -153,7 +155,7 @@ int main(int argc,
[Xenomai-core] Re: Move rtdm_irq_enable close to rtdm_irq_request
Jan Kiszka wrote: Hi Wolfgang, in the process of preparing to merge rtdm_irq_enable into rtdm_irq_request I would like to check if the attached patch is ok, thus we could finally drop rtdm_irq_enable once the API is refactored. Please check carefully when the first IRQs may happen and what the handler expects to be initialised! SJA1000 /should/ be ok as it works with shared IRQs, but MSCAN does not (why, BTW?) and /may/ stumble. OK. Why should I use shared interrupts if there is no need? Most embedded PowerPC systems have a dedicated interrupt source. Wolfgang. Jan Index: ksrc/drivers/can/mscan/rtcan_mscan.c === --- ksrc/drivers/can/mscan/rtcan_mscan.c(revision 1559) +++ ksrc/drivers/can/mscan/rtcan_mscan.c(working copy) @@ -801,7 +801,8 @@ int __init rtcan_mscan_init_one(int idx) printk(ERROR! rtdm_irq_request for IRQ %d failed\n, irq); goto out_dev_free; } - +rtdm_irq_enable(dev-irq_handle); + mscan_chip_config(regs); @@ -814,8 +815,6 @@ int __init rtcan_mscan_init_one(int idx) rtcan_mscan_create_proc(dev); -rtdm_irq_enable(dev-irq_handle); - /* Remember initialized devices */ rtcan_mscan_devs[idx] = dev; Index: ksrc/drivers/can/sja1000/rtcan_sja1000.c === --- ksrc/drivers/can/sja1000/rtcan_sja1000.c(revision 1559) +++ ksrc/drivers/can/sja1000/rtcan_sja1000.c(working copy) @@ -747,6 +747,7 @@ int rtcan_sja1000_register(struct rtcan_ printk(ERROR! IRQ %d busy or invalid (code=%d)!\n, chip-irq_num, ret); return ret; } +rtdm_irq_enable(dev-irq_handle); sja1000_chip_config(dev); @@ -759,8 +760,6 @@ int rtcan_sja1000_register(struct rtcan_ rtcan_sja_create_proc(dev); -rtdm_irq_enable(dev-irq_handle); - return 0; out_irq_free: ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Re: CAN updates questions
Jan Kiszka wrote:
Hi Wolfgang,
as one result of a hacking session on a PPC405 with SJA1000 on board I
applied two minor fixes to rtcan_isa.c to SVN, see end of mail for
reference. The first one gave an interesting effect on big-endian
because irq is an integer, the second one reveals that we should do some
multiport test with the ISA driver soon.
OK, I see. Unfortunately I do not have a ISA CAN device for testing.
Questions arose regarding the meaning of rtcan_device.can_sys_clock
(BTW, comment in rtcan_dev.h is wrong). What clock rate does it
describe? For the SJA1000 drivers its obviously clock/2. I'm asking
because of a) the output in rtcan_calc_bit_time() and b) the module
parameter of rtcan_isa and its description. We first hacked 16 MHz into
the latter yesterday as I didn't recall quickly enough that our Phytec
board also runs at 16 MHZ, thus the default value of 8 MHZ was already
correct. Confused? At least we were...
You have to define the real CAN system clock, which is 16/2 = 8 Mhz for
most SJA 1000 hardware even if the oscillator is running at 16 MHz. I
will add some reasonable note to rtcan_dev.h
And another suggestion: In order make module names shorter, what about
the renaming xeno_rtcan* - xeno_can*?
Fine for me.
Then we will soon have to discuss how to deal with a rtcan_isa
derivative that uses ioremapped memory instead of ports (naming,
separation or integration).
We could add a generic device similar to ISA (or extend ISA accordingly).
Jan
Wolfgang.
--
Index: ksrc/drivers/can/sja1000/rtcan_isa.c
===
--- ksrc/drivers/can/sja1000/rtcan_isa.c(Revision 1564)
+++ ksrc/drivers/can/sja1000/rtcan_isa.c(Arbeitskopie)
@@ -56,7 +56,7 @@ static u8 ocr[RTCAN_ISA_MAX_DEV];
static u8 cdr[RTCAN_ISA_MAX_DEV];
compat_module_short_param_array(isa, RTCAN_ISA_MAX_DEV);
-compat_module_byte_param_array(irq, RTCAN_ISA_MAX_DEV);
+compat_module_int_param_array(irq, RTCAN_ISA_MAX_DEV);
compat_module_int_param_array(clock, RTCAN_ISA_MAX_DEV);
compat_module_byte_param_array(ocr, RTCAN_ISA_MAX_DEV);
compat_module_byte_param_array(cdr, RTCAN_ISA_MAX_DEV);
@@ -187,9 +187,10 @@ static void __exit rtcan_isa_exit(void)
int i;
struct rtcan_device *dev;
-for (i = 0, dev = rtcan_isa_devs[i];
-i RTCAN_ISA_MAX_DEV dev != NULL;
-i++) {
+for (i = 0; i RTCAN_ISA_MAX_DEV; i++) {
+ dev = rtcan_isa_devs[i];
+ if (!dev)
+ continue;
rtcan_sja1000_unregister(dev);
}
}
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Re: CAN updates questions
Wolfgang Grandegger wrote: Hi Matthias, Matthias Fuchs wrote: Hi Wolfgang, Wolfgang Grandegger wrote: You have to define the real CAN system clock, which is 16/2 = 8 Mhz for most SJA 1000 hardware even if the oscillator is running at 16 MHz. I will add some reasonable note to rtcan_dev.h Is there any special reason for this? Wouldn't it be more meaningful to pass the SJA1000 externally applied clock frequency? I can imagine that others will also run into this issue as Jan and I did yesterday ;-) The frequency is used to calculate reasonable bit-timing parameters, not only for SJA 1000. It's used in a similar way in the Linux socket CAN driver. But the value passed via module parameter clock could be the more meaning full clock frequency for SJA 1000 drivers, of course. Then we will soon have to discuss how to deal with a rtcan_isa derivative that uses ioremapped memory instead of ports (naming, separation or integration). We could add a generic device similar to ISA (or extend ISA accordingly). The SJA1000 isa driver is very simple - and so is the modified version for the memory mapped SJA1000. I think that merging both ways of access to the SJA1000 into a single driver will make the code much more dirty. I would prefer different source files (= different drivers). I agree. It would be a compromise to add support for boards that use some kind of indirect addressing to access the SJA1000 (address + data register) into the isa and mem versions of the driver. Fine if this could be done in a generic way. We also should add a generic PCI driver sooner than later. One more proposal: I think many (old) ISA drivers name the module parameter for the ISA io port io instead of isa. For the memory mapped SJA1000 driver, I'd like to call the parameter mem. Well, I cannot remember why I used the name isa. Common is io or port or ioport, indeed. io and mem or ioport and iomem would be fine for me. Wolfgang. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] No hardware interrupts with xenomai on ppc405
Hi Matthias, Matthias Fuchs wrote: Hi, I was trying to use some external hardware interupts on a PPC405 board as part of a hacking session with Jan to bring up the rtcan driver on this board. Here are some versions: Linux Kernel: 2.6.14 Adeos: 1.3-07 Xenomai: from svn (2.3pre, last friday night) The first interrupt interrupt was always fine. When the 2nd interupt occured, it was never handled and did not cause any action. We used the ipipe-tracer and did not see anything related to the 2nd and any further interrupt. I think that the hardware interrupt is somehow masked and therefore never result in any action. So the handling of the first interrupt might be incorrect. This seems to be ppc or even ppc4xx related because I assume that x86 platforms do not have this issue. Is this an Adeos issue. I will do the same test on a 2.4 kernel next week - if nobody tells me that this will be a waste of time. Could you please add printk statements to the ack, enable and end functions to arch/ppc/syslib/ppc4xx_pic.c if the irq number matches. Please print also SR, ER and status. Wolfgang. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] No hardware interrupts with xenomai on ppc405
Matthias Fuchs wrote:
On Sunday 10 September 2006 13:02, Wolfgang Grandegger wrote:
Hi Matthias,
Matthias Fuchs wrote:
Hi,
I was trying to use some external hardware interupts on a PPC405 board
as part of a hacking session with Jan to bring up the rtcan driver on
this board.
Could you please add printk statements to the ack, enable and end
functions to arch/ppc/syslib/ppc4xx_pic.c if the irq number matches.
Please print also SR, ER and status.
1) insmodding the driver:
bash-3.00# modprobe xeno_rtcan_isa mem=0xf000 irq=25
rtcan: registered rtcan0
_enable: ER=003f0040, SR=c000
2) receiving
bash-3.00# /sbin/rtcanconfig rtcan0 -b 50 up
bash-3.00# ./bin/rtcanrecv rtcan0
_ack: ER=003f, SR=c040
_end: ER=003f, SR=c000
#0: (1) 0x000 [8] 00 00 00 00 01 00 00 00
OK. I will lookup the meaning later today.
That's it. When sending a 2nd message to the board, nothing happens.
We have a LED on the SJA1000 interrupt signal. After sending the 2nd message
this LED stays on, so the interrupt is never handled.
It seems that the interrupt is not reenabled (bit 25) in the end function.
Could you please add a printout of status. It's important that the
following if statement is entered in the end function:
if (!(status (IRQ_DISABLED | IRQ_INPROGRESS))) {
ppc_cached_irq_mask[n] |= mask;
mtdcr(DCRN_UIC_ER(UIC##n), ppc_cached_irq_mask[n]);
}
And could you also try replacing all lines
if (status IRQ_LEVEL) {
with
if (status IRQ_LEVEL || irq == your-irq) {
Thanks.
Wolfgang.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] No hardware interrupts with xenomai on ppc405
Matthias Fuchs wrote:
Hello Philippe,
that helps. I will do some further testing.
Matthias
On Monday 11 September 2006 12:20, Philippe Gerum wrote:
It's likely an Adeos issue. Could you try this patch? TIA,
--- arch/ppc/syslib/ppc4xx_pic.c~ 2005-10-28 02:02:08.0 +0200
+++ arch/ppc/syslib/ppc4xx_pic.c2006-09-11 12:18:14.0 +0200
@@ -72,7 +72,8 @@
mtdcr(DCRN_UIC_SR(UIC##n), mask); \
ACK_UIC##n##_PARENT \
} \
- if (!(status (IRQ_DISABLED | IRQ_INPROGRESS))) { \
+ if (!ipipe_root_domain_p || \
+ !(status (IRQ_DISABLED | IRQ_INPROGRESS))) { \
ppc_cached_irq_mask[n] |= mask; \
mtdcr(DCRN_UIC_ER(UIC##n), ppc_cached_irq_mask[n]); \
} \
Philippe, could you please explain the problem in more detail? And what
are the consequences for other PowerPC ARCs and PICs, also for Linux 2.4?
Thanks.
Wolfgang.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] No hardware interrupts with xenomai on ppc405
Philippe Gerum wrote:
On Mon, 2006-09-11 at 16:22 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
On Mon, 2006-09-11 at 14:20 +0200, Wolfgang Grandegger wrote:
Matthias Fuchs wrote:
Hello Philippe,
that helps. I will do some further testing.
Matthias
On Monday 11 September 2006 12:20, Philippe Gerum wrote:
It's likely an Adeos issue. Could you try this patch? TIA,
--- arch/ppc/syslib/ppc4xx_pic.c~ 2005-10-28 02:02:08.0 +0200
+++ arch/ppc/syslib/ppc4xx_pic.c2006-09-11 12:18:14.0 +0200
@@ -72,7 +72,8 @@
mtdcr(DCRN_UIC_SR(UIC##n), mask); \
ACK_UIC##n##_PARENT \
} \
- if (!(status (IRQ_DISABLED | IRQ_INPROGRESS))) { \
+ if (!ipipe_root_domain_p || \
+ !(status (IRQ_DISABLED | IRQ_INPROGRESS))) { \
ppc_cached_irq_mask[n] |= mask; \
mtdcr(DCRN_UIC_ER(UIC##n), ppc_cached_irq_mask[n]); \
} \
Philippe, could you please explain the problem in more detail? And what
are the consequences for other PowerPC ARCs and PICs, also for Linux 2.4?
The issue lies in the fact that PICs *_end() routines may be called over
the Xenomai domain, and actually are, most of the time, since
xnintr_irq_handler() -which invokes xnarch_end_irq()- is always called
from the the Xenomai stage in the Adeos pipeline.
In such a case, we must not check for the Linux-defined IRQ bits (e.g.
IRQ_INPROGRESS), and always send the eoi, since those bits are not
relevant to the Xenomai context. The patch above ensures this.
And yes, the 2.4 patch has the very same problem, which should be fixed
the same way for all supported ppc platforms in the various PIC
management code. Oops.
And why didn't this render PPC-over-2.4 useless, i.e. what is special
about this 405-scenario?
A possible explanation is that configurations only using the timer IRQ
are not affected, since the decrementer is not subject to this issue
(the tick handler returns XN_ISR_NOENABLE anyway).
I run RT-Socket-CAN on a CAN PCI Card on my MPC5200 without any
problems, so far (under Linux 2.4). Here the end function of the PIC:
static void
mpc5xxx_ic_end(unsigned int irq)
{
if (!(irq_desc[irq].status (IRQ_DISABLED | IRQ_INPROGRESS)))
mpc5xxx_ic_enable(irq);
}
Matthias, have you printed out the value of status? I'm just curious.
Wolfgang.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] No hardware interrupts with xenomai on ppc405
Matthias Fuchs wrote:
On Monday 11 September 2006 17:46, Wolfgang Grandegger wrote:
A possible explanation is that configurations only using the timer IRQ
are not affected, since the decrementer is not subject to this issue
(the tick handler returns XN_ISR_NOENABLE anyway).
I run RT-Socket-CAN on a CAN PCI Card on my MPC5200 without any
problems, so far (under Linux 2.4). Here the end function of the PIC:
static void
mpc5xxx_ic_end(unsigned int irq)
{
if (!(irq_desc[irq].status (IRQ_DISABLED | IRQ_INPROGRESS)))
mpc5xxx_ic_enable(irq);
}
Matthias, have you printed out the value of status? I'm just curious.
Wolfgang.
Here it comes:
bash-3.00# ./bin/rtcansend rtcan0 -i 0 1 2 3 4
_end: status=0042
bash-3.00# ./bin/rtcansend rtcan0 -i 0 1 2 3 4
_end: status=0042
bash-3.00# ./bin/rtcansend rtcan0 -i 0 1 2 3 4
_end: status=0042
So it's IRQ_DISABLED (=2).
In 2.6 the interrupts are disabled by default. Then the attached patch
for Xenomai should help.
Wolfgang.
+ diff -u xenomai/ksrc/arch/powerpc/hal.c.IRQEND xenomai/ksrc/arch/powerpc/hal.c
--- xenomai/ksrc/arch/powerpc/hal.c.IRQEND 2006-08-23 22:12:17.0 +0200
+++ xenomai/ksrc/arch/powerpc/hal.c 2006-09-11 20:00:32.0 +0200
@@ -326,6 +326,7 @@
rthal_irq_descp(irq)-handler-enable == NULL)
return -ENODEV;
+rthal_irq_descp(irq)-status = ~IRQ_DISABLED;
rthal_irq_descp(irq)-handler-enable(irq);
return 0;
@@ -341,6 +342,7 @@
rthal_irq_descp(irq)-handler-disable == NULL)
return -ENODEV;
+rthal_irq_descp(irq)-status |= IRQ_DISABLED;
rthal_irq_descp(irq)-handler-disable(irq);
return 0;
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] No hardware interrupts with xenomai on ppc405
Matthias Fuchs wrote:
On Monday 11 September 2006 20:13, Wolfgang Grandegger wrote:
In 2.6 the interrupts are disabled by default. Then the attached patch
for Xenomai should help.
Wolfgang.
Your patch also works fine. Now what's the recommended solution? I noticed
that Philippe already checked in an Adeos fix.
As mentioned, in Linux 2.6 (generic IRQ layer), IRQs are disabled by
default in kernel/irq/handle.c:
irq_desc_t irq_desc[NR_IRQS] __cacheline_aligned = {
[0 ... NR_IRQS-1] = {
.status = IRQ_DISABLED,
.handler = no_irq_type,
.lock = SPIN_LOCK_UNLOCKED
}
};
Till now, I haven't found IPIPE/Xenomai related code removing the
IRQ_DISABLED bit. But I wonder why it's working for x86. Maybe I have
missed something.
In Linux 2.4, the status field is initialized to 0 (in
arch/ppc/kernel/irq.c) not making trouble:
irq_desc_t irq_desc[NR_IRQS] __cacheline_aligned =
{ [0 ... NR_IRQS-1] = { 0, NULL, NULL, 0, SPIN_LOCK_UNLOCKED}};
At least my CAN PCI card on a MPC5200 works fine.
Philippe, do we really need these ugly PIC patches?
Wolfgang.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] rtcan_mem - CAN driver for memory mapped SJA1000 controllers
Hi Matthias,
Matthias Fuchs wrote:
Hi,
attached you will find a patch that adds support for memory mapped SJA1000 CAN
controllers as they often can be found on embedded boards. The driver is
based on the rtmen_isa driver.
What about using request_mem_region()? While looking to the driver I now
realize, that it's mainly duplicated code. Does it not make more sense
to make a combined io/mem driver. If io address 32K it's an io driver
else a mem driver.
The driver has been tested on esd's embedded PowerPC boards with AMCC PPC405
CPUs.
Thanks to Jan for giving me some introduction to Xenomai during a nightly
session last friday.
There's one thing a I am not very satisfied with :-) Why passing half of the
external clock frequency to the module. Because of compatiblity reasons I
kept this behavior of the clock paramter from the ISA driver.
The attached patch fixes this and replaces the module parameter isa
with io. I also tend to rename the driver into rtcan_io instead
rtcan_isa if we keep it.
Wolfgang.
Matthias
Index: ksrc/drivers/can/sja1000/Kconfig
===
--- ksrc/drivers/can/sja1000/Kconfig(revision 1564)
+++ ksrc/drivers/can/sja1000/Kconfig(working copy)
@@ -13,6 +13,16 @@
int Maximum number of ISA devices
default 4
+config XENO_DRIVERS_RTCAN_SJA1000_MEM
+ depends on XENO_DRIVERS_RTCAN_SJA1000
+ tristate Memory mapped controllers
+ default n
+
+config XENO_DRIVERS_RTCAN_SJA1000_MEM_MAX_DEV
+ depends on XENO_DRIVERS_RTCAN_SJA1000_MEM
+ int Maximum number of memory mapped controllers
+ default 4
+
config XENO_DRIVERS_RTCAN_SJA1000_PEAK_PCI
depends on XENO_DRIVERS_RTCAN_SJA1000
tristate PEAK PCI Card
Index: ksrc/drivers/can/sja1000/rtcan_mem.c
===
--- ksrc/drivers/can/sja1000/rtcan_mem.c(revision 0)
+++ ksrc/drivers/can/sja1000/rtcan_mem.c(revision 0)
@@ -0,0 +1,206 @@
+/*
+ * Copyright (C) 2006 Matthias Fuchs [EMAIL PROTECTED],
+ *Jan Kiszka [EMAIL PROTECTED]
+ *
+ * RTCAN driver for memory mapped SJA1000 CAN controller
+ * This code has been tested on esd's CPCI405/EPPC405 PPC405 systems.
+ *
+ * This driver is derived from the rtcan-isa driver by
+ * Wolfgang Grandegger and Sebastian Smolorz.
+ *
+ * Copyright (C) 2006 Wolfgang Grandegger [EMAIL PROTECTED]
+ * Copyright (C) 2005, 2006 Sebastian Smolorz
+ * [EMAIL PROTECTED]
+ *
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; eitherer version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software Foundation,
+ * Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+#include linux/module.h
+#include linux/ioport.h
+#include linux/delay.h
+
+#include rtdm/rtdm_driver.h
+
+#include rtdm/rtcan.h
+#include rtcan_dev.h
+#include rtcan_raw.h
+#include rtcan_internal.h
+#include rtcan_sja1000.h
+#include rtcan_sja1000_regs.h
+
+#define RTCAN_DEV_NAMErtcan%d
+#define RTCAN_DRV_NAMEsja1000-mem
+
+#ifdef CONFIG_XENO_DRIVERS_RTCAN_MEM_MAX_DEVS
+#define RTCAN_MEM_MAX_DEV CONFIG_XENO_DRIVERS_RTCAN_MEM_MAX_DEV
+#else
+#define RTCAN_MEM_MAX_DEV 2
+#endif
+
+static char *mem_board_name = mem mapped;
+
+MODULE_AUTHOR(Matthias Fuchs [EMAIL PROTECTED]);
+MODULE_DESCRIPTION(RTCAN driver for memory mapped SJA1000 controller);
+MODULE_SUPPORTED_DEVICE(mem mapped);
+MODULE_LICENSE(GPL);
+
+static u32 mem[RTCAN_MEM_MAX_DEV];
+static int irq[RTCAN_MEM_MAX_DEV];
+static u32 clock[RTCAN_MEM_MAX_DEV];
+static u8 ocr[RTCAN_MEM_MAX_DEV];
+static u8 cdr[RTCAN_MEM_MAX_DEV];
+
+compat_module_int_param_array(mem, RTCAN_MEM_MAX_DEV);
+compat_module_int_param_array(irq, RTCAN_MEM_MAX_DEV);
+compat_module_int_param_array(clock, RTCAN_MEM_MAX_DEV);
+compat_module_byte_param_array(ocr, RTCAN_MEM_MAX_DEV);
+compat_module_byte_param_array(cdr, RTCAN_MEM_MAX_DEV);
+
+MODULE_PARM_DESC(mem, The io-memory address);
+MODULE_PARM_DESC(irq, The interrupt number);
+MODULE_PARM_DESC(clock, CAN system clock frequency (default 8 MHz));
+MODULE_PARM_DESC(ocr, Value of output control register (default 0x1a));
+MODULE_PARM_DESC(cdr, Value of clock divider register (default 0xc8);
+
+#define RTCAN_MEM_RANGE 0x80
+
+struct rtcan_mem
+{
+u8 *mem;
+};
+
+static struct
Re: [Xenomai-core] [PATCH] rtcan_mem - CAN driver for memory mapped SJA1000 controllers
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
Hi Matthias,
Matthias Fuchs wrote:
Hi,
attached you will find a patch that adds support for memory mapped
SJA1000 CAN controllers as they often can be found on embedded boards.
The driver is based on the rtmen_isa driver.
What about using request_mem_region()?
(and this would also give RTCAN_DRV_NAME some sense again :))
While looking to the driver I now
realize, that it's mainly duplicated code. Does it not make more sense
to make a combined io/mem driver. If io address 32K it's an io driver
else a mem driver.
And provide two sets of readreg/writereg? What about differences in
Yes.
chip-irq_flags, are they always like io=edge, mem=level? What about
defaults for CDR and OCR? Are the arbitrary anyway or do they correlate
somehow to the access type?
Another module parameter for the irq_flags makes sense, indeed. OCR and
CDR do not affect the access type. It more defines some electrical
characteristics.
/* Output control register */
enum SJA1000_PELI_OCR {
SJA_OCR_MODE_BIPHASE = 0,
SJA_OCR_MODE_TEST= 1,
SJA_OCR_MODE_NORMAL = 2,
SJA_OCR_MODE_CLOCK = 3,
SJA_OCR_TX0_INVERT = 12,
SJA_OCR_TX0_PULLDOWN = 13,
SJA_OCR_TX0_PULLUP = 23,
SJA_OCR_TX0_PUSHPULL = 33,
SJA_OCR_TX1_INVERT = 15,
SJA_OCR_TX1_PULLDOWN = 16,
SJA_OCR_TX1_PULLUP = 26,
SJA_OCR_TX1_PUSHPULL = 36
};
enum SJA1000_PELI_CDR {
SJA_CDR_CLK_OFF = 13, /* Clock off (CLKOUT pin) */
SJA_CDR_CBP = 16, /* CAN input comparator bypass */
SJA_CDR_CAN_MODE = 17 /* CAN mode: 1 = PeliCAN */
};
When we do not find answers right now (maybe in other Linux CAN
stacks?), we may postpone the merge and keep is separated until more
hardware pops up with more use-cases.
No hurry, of course.
The driver has been tested on esd's embedded PowerPC boards with AMCC
PPC405 CPUs.
Thanks to Jan for giving me some introduction to Xenomai during a
nightly session last friday.
There's one thing a I am not very satisfied with :-) Why passing half
of the external clock frequency to the module. Because of compatiblity
reasons I kept this behavior of the clock paramter from the ISA driver.
The attached patch fixes this and replaces the module parameter isa
with io. I also tend to rename the driver into rtcan_io instead
rtcan_isa if we keep it.
Wolfgang.
Jan
Wolfgang.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] rtcan_mem - CAN driver for memory mapped SJA1000 controllers
Matthias Fuchs wrote: Hi Wolfgang, On Tuesday 12 September 2006 14:22, Wolfgang Grandegger wrote: What about using request_mem_region()? While looking to the driver I now ... will be added, of course. realize, that it's mainly duplicated code. Does it not make more sense to make a combined io/mem driver. If io address 32K it's an io driver else a mem driver. Yes, that's possible. We can also decide on the used module parameter (mem or io) what is to do. Passing both results in an error. You are right that its duplicated code. But the driver is very simple. It nearly does nothing but mapping, implementing register access callbacks, registering and cleanup when unloading. But the driver differs in all these points from the isa/io colleague. I like shot an simple drivers, so that you do not have to care about breaking the isa/io part when modifying the mem part. There's one thing a I am not very satisfied with :-) Why passing half of the external clock frequency to the module. Because of compatiblity reasons I kept this behavior of the clock paramter from the ISA driver. The attached patch fixes this and replaces the module parameter isa with io. I also tend to rename the driver into rtcan_io instead rtcan_isa if we keep it. Sounds good. Jan, could you apply this patch to avoid further confusion? The real CAN clock frequency listed also in the proc file system is half of the oscillator clock. Some more doc might help to avoid further confusion. Wolfgang. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] RTCAN_USE_REFCOUNT issue in rtcan_dev.h
Matthias Fuchs wrote: Hi Jan, I think there's is little typo in rtcan_dev.h: Index: rtcan_dev.h === --- rtcan_dev.h (revision 1564) +++ rtcan_dev.h (working copy) @@ -45,7 +45,7 @@ /* Suppress handling of refcount if module support is not enabled * or modules cannot be unloaded */ -#if defined(CONFIG_MODULES) !defined(CONFIG_MODULE_UNLOAD) +#if defined(CONFIG_MODULES) defined(CONFIG_MODULE_UNLOAD) #define RTCAN_USE_REFCOUNT #endif This simple patch will allow unloading of modules. Argh, I interpreted the meaning of CONFIG_MODULE_UNLOAD the other way round. But your fix will not work for 2.4, as there is no CONFIG_MODULE_UNLOAD. The attached one should be OK. Thanks. Wolfgang. + diff -u xenomai/ksrc/drivers/can/rtcan_dev.h.REFCOUNT xenomai/ksrc/drivers/can/rtcan_dev.h --- xenomai/ksrc/drivers/can/rtcan_dev.h.REFCOUNT 2006-08-23 22:12:20.0 +0200 +++ xenomai/ksrc/drivers/can/rtcan_dev.h 2006-09-12 18:28:57.0 +0200 @@ -45,7 +45,9 @@ /* Suppress handling of refcount if module support is not enabled * or modules cannot be unloaded */ -#if defined(CONFIG_MODULES) !defined(CONFIG_MODULE_UNLOAD) + +#ifdef CONFIG_MODULES +#if LINUX_VERSION_CODE KERNEL_VERSION(2,5,0) || defined(CONFIG_MODULE_UNLOAD) #define RTCAN_USE_REFCOUNT #endif ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] rtcan_mem - CAN driver for memory mapped SJA1000 controllers
Matthias Fuchs wrote: Hi, here's the 2nd try: - updated external clock frequency handling - use request_mem_region() before remapping memory - renamed local variable mem to vmem in clean loop because it shadowed a module parameter I have one more comment, sorry. I think you should use: volatile void __iomem *vmem; and the cleanup in case of error is not OK. See below. Now it's on you to decide if we should merge and/or rename. I wouldn't merge because of my former arguments. But do not care about me:-) Fine for me for the time being. Matthias Wolfgang On Tuesday 12 September 2006 14:22, Wolfgang Grandegger wrote: Hi Matthias, Matthias Fuchs wrote: Hi, attached you will find a patch that adds support for memory mapped SJA1000 CAN controllers as they often can be found on embedded boards. The driver is based on the rtmen_isa driver. What about using request_mem_region()? While looking to the driver I now realize, that it's mainly duplicated code. Does it not make more sense to make a combined io/mem driver. If io address 32K it's an io driver else a mem driver. Index: ksrc/drivers/can/sja1000/Kconfig === --- ksrc/drivers/can/sja1000/Kconfig(revision 1564) +++ ksrc/drivers/can/sja1000/Kconfig(working copy) @@ -13,6 +13,16 @@ int Maximum number of ISA devices default 4 +config XENO_DRIVERS_RTCAN_SJA1000_MEM + depends on XENO_DRIVERS_RTCAN_SJA1000 + tristate Memory mapped controllers + default n + +config XENO_DRIVERS_RTCAN_SJA1000_MEM_MAX_DEV + depends on XENO_DRIVERS_RTCAN_SJA1000_MEM + int Maximum number of memory mapped controllers + default 4 + config XENO_DRIVERS_RTCAN_SJA1000_PEAK_PCI depends on XENO_DRIVERS_RTCAN_SJA1000 tristate PEAK PCI Card Index: ksrc/drivers/can/sja1000/rtcan_mem.c === --- ksrc/drivers/can/sja1000/rtcan_mem.c(revision 0) +++ ksrc/drivers/can/sja1000/rtcan_mem.c(revision 0) @@ -0,0 +1,213 @@ +/* + * Copyright (C) 2006 Matthias Fuchs [EMAIL PROTECTED], + *Jan Kiszka [EMAIL PROTECTED] + * + * RTCAN driver for memory mapped SJA1000 CAN controller + * This code has been tested on esd's CPCI405/EPPC405 PPC405 systems. + * + * This driver is derived from the rtcan-isa driver by + * Wolfgang Grandegger and Sebastian Smolorz. + * + * Copyright (C) 2006 Wolfgang Grandegger [EMAIL PROTECTED] + * Copyright (C) 2005, 2006 Sebastian Smolorz + * [EMAIL PROTECTED] + * + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by + * the Free Software Foundation; eitherer version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software Foundation, + * Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. + */ + +#include linux/module.h +#include linux/ioport.h +#include linux/delay.h + +#include rtdm/rtdm_driver.h + +#include rtdm/rtcan.h +#include rtcan_dev.h +#include rtcan_raw.h +#include rtcan_internal.h +#include rtcan_sja1000.h +#include rtcan_sja1000_regs.h + +#define RTCAN_DEV_NAMErtcan%d +#define RTCAN_DRV_NAMEsja1000-mem + +#ifdef CONFIG_XENO_DRIVERS_RTCAN_MEM_MAX_DEVS +#define RTCAN_MEM_MAX_DEV CONFIG_XENO_DRIVERS_RTCAN_MEM_MAX_DEV +#else +#define RTCAN_MEM_MAX_DEV 2 +#endif + +static char *mem_board_name = mem mapped; + +MODULE_AUTHOR(Matthias Fuchs [EMAIL PROTECTED]); +MODULE_DESCRIPTION(RTCAN driver for memory mapped SJA1000 controller); +MODULE_SUPPORTED_DEVICE(mem mapped); +MODULE_LICENSE(GPL); + +static u32 mem[RTCAN_MEM_MAX_DEV]; +static int irq[RTCAN_MEM_MAX_DEV]; +static u32 clock[RTCAN_MEM_MAX_DEV]; +static u8 ocr[RTCAN_MEM_MAX_DEV]; +static u8 cdr[RTCAN_MEM_MAX_DEV]; + +compat_module_int_param_array(mem, RTCAN_MEM_MAX_DEV); +compat_module_int_param_array(irq, RTCAN_MEM_MAX_DEV); +compat_module_int_param_array(clock, RTCAN_MEM_MAX_DEV); +compat_module_byte_param_array(ocr, RTCAN_MEM_MAX_DEV); +compat_module_byte_param_array(cdr, RTCAN_MEM_MAX_DEV); + +MODULE_PARM_DESC(mem, The io-memory address); +MODULE_PARM_DESC(irq, The interrupt number); +MODULE_PARM_DESC(clock, External clock frequency (default 16 MHz)); +MODULE_PARM_DESC(ocr, Value of output control register (default 0x1a)); +MODULE_PARM_DESC(cdr, Value of clock divider register (default 0xc8); + +#define RTCAN_MEM_RANGE 0x80 + +struct
Re: [Xenomai-core] Problem with periodic timer on PPC40x identified
Hi Niklaus,
Niklaus Giger wrote:
Hi
Finally I got some time to debug the whole problem with my BDI.
I see that in hal.c thal_set_local_cpu_timer the PIT is loaded with a value of
568 which is far too low, as the PIT is running at 400 MHz. So it will
trigger an interrupt every 1,4 microsecond and therefore overload the system.
I am not sure about the time units stored in __ipipe_decr_ticks. I tried to
use 400 as my board is running at 400 MHz.
A quick breakpoint in ppc4xx_calibrate_decr in the file
arch/syslib/ppc4xx_setup.c verified that bdinfo has the correct value of
400'000'000 as frequency.
In hal.c and ipipe-core are two occurences of
mtspr(SPRN_PIT, __ipipe_decr_ticks);
which I replaced by the above computed constant
mtspr(SPRN_PIT, __ipipe_decr_ticks * 400);
Now the the board comes up, but calling in the vxworks skin
taskDelay(sysClkRateGet()*10) delays me only about 5 seconds and not 10 as
expected.
I have one possible explanation that the value of 568 is the result of a
implicit truncation to 32 bits in ipipe_tune_timer. tb_ticks_per_jiffy is
160, sysClkRate is 1. Therefore a maximal delay of 1 ms = 1000*1000
ns leads to 1000*1000*16000 = 0x25'40BE'4000.
If would be nice if somebode could shed some light on this issue.
I briefly look why the value of __ipipe_decr_ticks is bogus. Maybe the
calculation fails due to 32-bit constraints in
arch/ppc/kernel/ipipe-core.c:pipe_tune_timer():
int ipipe_tune_timer(unsigned long ns, int flags)
{
unsigned long x, ticks;
if (flags IPIPE_RESET_TIMER)
ticks = tb_ticks_per_jiffy;
else {
ticks = ns * tb_ticks_per_jiffy / (10 / HZ);
^^^
if (ticks tb_ticks_per_jiffy)
return -EINVAL;
}
x = ipipe_critical_enter(__ipipe_set_decr); /* Sync with all
CPUs */
__ipipe_decr_ticks = ticks;
__ipipe_set_decr();
ipipe_critical_exit(x);
return 0;
}
Does replacing the calculation of ticks with
ticks = ns * (tb_ticks_per_jiffy / 1) / (10 / HZ);
help. A proper calculation might use mulhwu or rthal_imuldiv.
Wolfgang.
My preliminary patch looked like this, but I am sure that we need quite a
different solution.
+++ ksrc/arch/powerpc/hal.c (Arbeitskopie)
@@ -81,7 +81,9 @@
*/
static void rthal_set_local_cpu_timer(void)
{
+#ifndef CONFIG_40x
long ticks;
+#endif
rthal_declare_cpuid;
rthal_load_cpuid();
@@ -90,7 +92,7 @@
#ifdef CONFIG_40x
/* Enable and set auto-reload. */
mtspr(SPRN_TCR, mfspr(SPRN_TCR) | TCR_ARE);
-mtspr(SPRN_PIT, __ipipe_decr_ticks);
+mtspr(SPRN_PIT, __ipipe_decr_ticks * 400); /* TODO: How do we get this
value from the board info */
#else /* !CONFIG_40x */
ticks = (long)(__ipipe_decr_next[cpuid] - __ipipe_read_timebase());
set_dec(ticks 0 ? ticks : 0);
Index: ksrc/arch/powerpc/patches/adeos-ipipe-2.6.14-ppc-1.4-00.patch
===
--- ksrc/arch/powerpc/patches/adeos-ipipe-2.6.14-ppc-1.4-00.patch (Revision
1650)
+++ ksrc/arch/powerpc/patches/adeos-ipipe-2.6.14-ppc-1.4-00.patch
(Arbeitskopie)
@@ -3581,7 +3581,8 @@
+#ifdef CONFIG_40x
+ /* Enable and set auto-reload. */
+ mtspr(SPRN_TCR, mfspr(SPRN_TCR) | TCR_ARE);
-+ mtspr(SPRN_PIT, __ipipe_decr_ticks);
++ mtspr(SPRN_PIT, __ipipe_decr_ticks * 400 ); /* TODO: How do we get this
value from the board info */
+
+#else /* !CONFIG_40x */
+ __ipipe_decr_next[cpuid] = __ipipe_read_timebase() + __ipipe_decr_ticks;
+ set_dec(__ipipe_decr_ticks);
Best regards
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Problem with periodic timer on PPC40x solved
Niklaus Giger wrote: Am Montag, 25. September 2006 17:57 schrieb Philippe Gerum: On Sun, 2006-09-24 at 23:07 +0200, Wolfgang Grandegger wrote: Niklaus Giger wrote: .. Ok, we can go for the lazy fix here, since this code is poised to disappear anyway. I've merged a variant of the above we already use for the ARM port, which scales down the period to microseconds instead of losing precision on the count of timebase ticks per jiffy. - ticks = ns * tb_ticks_per_jiffy / (10 / HZ); + ticks = (ns / 1000) * tb_ticks_per_jiffy / (100 / HZ); Thanks for finding this solution. I tried to understand mulhwu and mulhwu_scale_factor but couldn't figure out a correct solution in a short time. I took me also some time to understand the meaning. mulhwu(a,b) returns the high 32 bits (32..63) of a*b. A possible quick fix could be: if (mulhwu(ns, tb_ticks_per_jiffy) 0) ticks = (ns / 1000) * tb_ticks_per_jiffy / (100 / HZ); else ticks = ns * tb_ticks_per_jiffy / (10 / HZ); But Philippe already applied a reasonable fix. The buildbot cannot presently power on and off my PPC405 target board, as the my power outlet switching device is broken and has been sent back for a remplacement. I did however run some tests manually and have the following questions about the output: Why do I get negative values for latenciy values? Is the output of lines like Xenomai: Switching display-3238 to secondary mode after exception #1025 from user-space at 0x100033c4 (pid 3240) harmless or the result of a activated CONFIG_XENO_OPT_DEBUG.. option? Mon Sep 25 20:20:33 UTC 2006 running: ./run -- -T 5 -t2 # latency * * * Type ^C to stop this application. * Xenomai: Switching display-3238 to secondary mode after exception #1025 from user-space at 0x100033c4 (pid 3240) == Sampling period: 100 us == Test mode: in-kernel timer handler == All results in microseconds warming up... RTT| 00:00:01 (in-kernel timer handler, 100 us period, priority 99) RTH|-lat min|-lat avg|-lat max|-overrun|lat best|---lat worst RTD| -5.108| -4.754| -0.905| 0| -5.108| -0.905 RTD| -4.963| -4.871| 1.155| 0| -5.108| 1.155 Xenomai: Switching display-3238 to secondary mode after exception #1025 from user-space at 0xfda9638 (pid 3240) RTD| -4.963| -4.758| 16.020| 0| -5.108| 16.020 RTD| -6.313| -4.861| 10.980| 0| -6.313| 16.020 Xenomai: Switching display-3238 to secondary mode after exception #1025 from user-space at 0xfe7c1c4 (pid 3240) ---|||||- RTS| -6.313| -4.811| 16.020| 0|00:00:05/00:00:05 Xenomai: stopping RTDM services. Best regards ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Problem with periodic timer on PPC40x solved
Philippe Gerum wrote: On Tue, 2006-09-26 at 16:56 +0200, gilles.chanteperdrix wrote: -- Debut du message initial --- De : [EMAIL PROTECTED] A : [EMAIL PROTECTED] Copies : xenomai-core@gna.org Date : Tue, 26 Sep 2006 16:21:18 +0200 Objet : Re: [Xenomai-core] Problem with periodic timer on PPC40x solved On Mon, 2006-09-25 at 22:29 +0200, Niklaus Giger wrote: Am Montag, 25. September 2006 17:57 schrieb Philippe Gerum: On Sun, 2006-09-24 at 23:07 +0200, Wolfgang Grandegger wrote: Niklaus Giger wrote: .. Is the output of lines like Xenomai: Switching display-3238 to secondary mode after exception #1025 from user-space at 0x100033c4 (pid 3240) harmless or the result of a activated CONFIG_XENO_OPT_DEBUG.. option? A known hw issue seems to exist with the 405GP (revD), which causes the ESR to be incorrectly set upon FPU emulation trap, which would in turn cause the spurious exception to be relayed to the nucleus by Adeos. The patch below is _not_ the final fix, but rather a way to check if this message is indeed related to the FPU emulation on your board. Does it silence the exception without breaking the box? The FPU fault may be the result of the latency display thread using the FPU: on systems with emulated FPU, this looks normal. This said, we should not switch the task to secondary mode, but rather emulate the FPU ops in primary mode. To this end, we need to make sure that do_mathemu() is not going to choke over this context (e.g. preemption count check issues over CONFIG_PREEMPT when running unmodified uaccess routines). We additionally need to fix the program check exception handler to give the math emulation code a chance to handle the fault before we complain loudly at the nucleus. OK, but in general, soft-float emulation should be used on systems without FPU and this is even more important for real-time. This is a tool chain issue. Niklaus, what tool chain are you using? Wolfgang. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Problem with periodic timer on PPC40x solved
Philippe Gerum wrote: On Tue, 2006-09-26 at 18:28 +0200, Wolfgang Grandegger wrote: Philippe Gerum wrote: On Tue, 2006-09-26 at 16:56 +0200, gilles.chanteperdrix wrote: -- Debut du message initial --- De : [EMAIL PROTECTED] A : [EMAIL PROTECTED] Copies : xenomai-core@gna.org Date : Tue, 26 Sep 2006 16:21:18 +0200 Objet : Re: [Xenomai-core] Problem with periodic timer on PPC40x solved On Mon, 2006-09-25 at 22:29 +0200, Niklaus Giger wrote: Am Montag, 25. September 2006 17:57 schrieb Philippe Gerum: On Sun, 2006-09-24 at 23:07 +0200, Wolfgang Grandegger wrote: Niklaus Giger wrote: .. Is the output of lines like Xenomai: Switching display-3238 to secondary mode after exception #1025 from user-space at 0x100033c4 (pid 3240) harmless or the result of a activated CONFIG_XENO_OPT_DEBUG.. option? A known hw issue seems to exist with the 405GP (revD), which causes the ESR to be incorrectly set upon FPU emulation trap, which would in turn cause the spurious exception to be relayed to the nucleus by Adeos. The patch below is _not_ the final fix, but rather a way to check if this message is indeed related to the FPU emulation on your board. Does it silence the exception without breaking the box? The FPU fault may be the result of the latency display thread using the FPU: on systems with emulated FPU, this looks normal. This said, we should not switch the task to secondary mode, but rather emulate the FPU ops in primary mode. To this end, we need to make sure that do_mathemu() is not going to choke over this context (e.g. preemption count check issues over CONFIG_PREEMPT when running unmodified uaccess routines). We additionally need to fix the program check exception handler to give the math emulation code a chance to handle the fault before we complain loudly at the nucleus. OK, but in general, soft-float emulation should be used on systems without FPU and this is even more important for real-time. Makes sense. So maybe we should make this a more explicit and formal warning, to catch missing soft float emulation, actually. We could already print a compiler warning when the kernel is built with MATH_EMULATION=y. There are a few corner-case where it might make sense to have math emulation enabled e.g. you need to run a binary with hard FP instructions because you are unable to rebuild it from the sources. This is a tool chain issue. Niklaus, what tool chain are you using? Wolfgang. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Problem with periodic timer on PPC40x solved
Niklaus Giger wrote: Am Dienstag, 26. September 2006 22:23 schrieb Wolfgang Grandegger: Niklaus Giger wrote: Am Dienstag, 26. September 2006 18:28 schrieb Wolfgang Grandegger: Philippe Gerum wrote: On Tue, 2006-09-26 at 16:56 +0200, gilles.chanteperdrix wrote: OK, but in general, soft-float emulation should be used on systems without FPU and this is even more important for real-time. This is a tool chain issue. Niklaus, what tool chain are you using? In my .config I have MATH_EMULATION=y You seem to need that because your compiler generates code with hard FP instructions. You could check this with: $ ppc-linux-objdump -d prog|egrep :\s*[e-f] This does not return any match on my system. Oops, then your compiler seems _not_ to create hard FP instruction, otherwise you would get: ppc_82xx-objdump -d latency|egrep :\s*[e-f] latency: file format elf32-powerpc 100036ac: fc 21 f8 28 fsubf1,f1,f31 100036b4: fc 42 f8 28 fsubf2,f2,f31 100036c4: fc 63 f8 28 fsubf3,f3,f31 100036cc: fc 21 f0 24 fdivf1,f1,f30 100036dc: fc 84 f8 28 fsubf4,f4,f31 ... But looking at the disassembly of the latency program I have code like: 100081bc _restfpr_28_x: 100081bc: cb 8b ff e0 lfd f28,-32(r11) or 1000798c __floatsidf: 1000798c: 7c 08 02 a6 mflrr0 10007990: 2f 83 00 00 cmpwi cr7,r3,0 10007994: 94 21 ff c0 stwur1,-64(r1) 10007998: 90 01 00 44 stw r0,68(r1) 1000799c: 54 60 0f fe rlwinm r0,r3,1,31,31 100079a0: 90 01 00 14 stw r0,20(r1) 100079a4: 40 9e 00 24 bne-cr7,100079c8 __floatsidf+0x3c That's from soft float emulation. The toolchain is gcc-3.4.4-glibc-2.3.5/powerpc-405-linux-gnu built using Dan Kegel crosstool (Version 0.42 if I remember exactly). Shall I switch to another one? Maybe (likely) there is nothing wrong with your tool chain. The ELDK from DENX uses FP soft-emulation for 4xx (http://www.denx.de). Choose v3.1.1 for Linux 2.4 and v4 for Linux 2.6. I am breathing only PowerPC code on my Mac PowerBook (running Debian) and never managed to installed ELDK on it. (And even Detlev as a Debian developer couldn't recommend a simple way.) I remember Detlev's pain and frustration. But I assume that I specifying GLIBC_EXTRA_CONFIG=--without-fp in the powerpc-405.dat should be enough to make Dan Kegels crosstool emit Soft-FPU emulation. See above. I will try to run the tests at work where I have installed ELDK 4.0, but not yet a fully working environment. Therefore it may take some time to report a result back. I'm now a bit puzzled why a FP exception occurs. What happens if you disable MATH_EMULATION in your kernel (that's what I normally have). It will try the latency test on my Walnut-Board with CONFIG_XENO_OPT_DEBUG asap. Wolfgang. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Problem with periodic timer on PPC40x solved
Wolfgang Grandegger wrote: Niklaus Giger wrote: Am Dienstag, 26. September 2006 22:23 schrieb Wolfgang Grandegger: Niklaus Giger wrote: Am Dienstag, 26. September 2006 18:28 schrieb Wolfgang Grandegger: Philippe Gerum wrote: On Tue, 2006-09-26 at 16:56 +0200, gilles.chanteperdrix wrote: OK, but in general, soft-float emulation should be used on systems without FPU and this is even more important for real-time. This is a tool chain issue. Niklaus, what tool chain are you using? In my .config I have MATH_EMULATION=y You seem to need that because your compiler generates code with hard FP instructions. You could check this with: $ ppc-linux-objdump -d prog|egrep :\s*[e-f] This does not return any match on my system. Oops, then your compiler seems _not_ to create hard FP instruction, otherwise you would get: ppc_82xx-objdump -d latency|egrep :\s*[e-f] latency: file format elf32-powerpc 100036ac: fc 21 f8 28 fsubf1,f1,f31 100036b4: fc 42 f8 28 fsubf2,f2,f31 100036c4: fc 63 f8 28 fsubf3,f3,f31 100036cc: fc 21 f0 24 fdivf1,f1,f30 100036dc: fc 84 f8 28 fsubf4,f4,f31 ... But looking at the disassembly of the latency program I have code like: 100081bc _restfpr_28_x: 100081bc: cb 8b ff e0 lfd f28,-32(r11) or 1000798c __floatsidf: 1000798c: 7c 08 02 a6 mflrr0 10007990: 2f 83 00 00 cmpwi cr7,r3,0 10007994: 94 21 ff c0 stwur1,-64(r1) 10007998: 90 01 00 44 stw r0,68(r1) 1000799c: 54 60 0f fe rlwinm r0,r3,1,31,31 100079a0: 90 01 00 14 stw r0,20(r1) 100079a4: 40 9e 00 24 bne-cr7,100079c8 __floatsidf+0x3c That's from soft float emulation. The toolchain is gcc-3.4.4-glibc-2.3.5/powerpc-405-linux-gnu built using Dan Kegel crosstool (Version 0.42 if I remember exactly). Shall I switch to another one? Maybe (likely) there is nothing wrong with your tool chain. The ELDK from DENX uses FP soft-emulation for 4xx (http://www.denx.de). Choose v3.1.1 for Linux 2.4 and v4 for Linux 2.6. I am breathing only PowerPC code on my Mac PowerBook (running Debian) and never managed to installed ELDK on it. (And even Detlev as a Debian developer couldn't recommend a simple way.) I remember Detlev's pain and frustration. But I assume that I specifying GLIBC_EXTRA_CONFIG=--without-fp in the powerpc-405.dat should be enough to make Dan Kegels crosstool emit Soft-FPU emulation. See above. I will try to run the tests at work where I have installed ELDK 4.0, but not yet a fully working environment. Therefore it may take some time to report a result back. I'm now a bit puzzled why a FP exception occurs. What happens if you disable MATH_EMULATION in your kernel (that's what I normally have). It will try the latency test on my Walnut-Board with CONFIG_XENO_OPT_DEBUG asap. I'm unable to reproduce the problem of our Sycamore board with Linux 2.6.14: CPU: AMCC PowerPC 405GPr Rev. B at 333.333 MHz (PLB=133, OPB=66, EBC=66 MHz) Internal PCI arbiter enabled, PCI async ext clock used 16 kB I-Cache 16 kB D-Cache Board: Sycamore - AMCC PPC405GPr Evaluation Board Wolfgang. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Problem with periodic timer on PPC40x solved
Niklaus Giger wrote: Am Mittwoch, 27. September 2006 20:19 schrieb Wolfgang Grandegger: .. I'm now a bit puzzled why a FP exception occurs. What happens if you disable MATH_EMULATION in your kernel (that's what I normally have). It will try the latency test on my Walnut-Board with CONFIG_XENO_OPT_DEBUG asap. I'm unable to reproduce the problem of our Sycamore board with Linux 2.6.14: Can I you send me (maybe offline) your .config. I will also rebuild my rootfs from scratch. At work I have also a walnut board where I could run the tests. See attachment. And I tested with a Sycamore Evaluation Board, which uses the same processor as you have. Likely, it has nothing to do with the board. Does your kernel boot with MATH_EMULATION disabled? Can you then run user-space applications using FP. CPU: AMCC PowerPC 405GPr Rev. B at 333.333 MHz (PLB=133, OPB=66, EBC=66 MHz) Internal PCI arbiter enabled, PCI async ext clock used 16 kB I-Cache 16 kB D-Cache Board: Sycamore - AMCC PPC405GPr Evaluation Board Thanks for trying to reproduce the problem. # # Automatically generated make config: don't edit # Linux kernel version: 2.6.14 # Wed Sep 27 14:21:27 2006 # CONFIG_MMU=y CONFIG_GENERIC_HARDIRQS=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_PPC=y CONFIG_PPC32=y CONFIG_GENERIC_NVRAM=y CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_CLEAN_COMPILE=y CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y # CONFIG_SWAP is not set CONFIG_SYSVIPC=y # CONFIG_POSIX_MQUEUE is not set # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y # CONFIG_AUDIT is not set # CONFIG_HOTPLUG is not set CONFIG_KOBJECT_UEVENT=y # CONFIG_IKCONFIG is not set CONFIG_INITRAMFS_SOURCE= CONFIG_EMBEDDED=y # CONFIG_KALLSYMS is not set CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y # CONFIG_EPOLL is not set # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SHMEM=y CONFIG_CC_ALIGN_FUNCTIONS=0 CONFIG_CC_ALIGN_LABELS=0 CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_OBSOLETE_MODPARM=y CONFIG_MODVERSIONS=y # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y # # Real-time sub-system # CONFIG_XENOMAI=y CONFIG_XENO_OPT_NUCLEUS=y CONFIG_XENO_OPT_PERVASIVE=y # CONFIG_XENO_OPT_ISHIELD is not set # CONFIG_XENO_OPT_RPIDISABLE is not set CONFIG_XENO_OPT_SECURITY_ACCESS=y CONFIG_XENO_OPT_PIPELINE_HEAD=y CONFIG_XENO_OPT_PIPE=y CONFIG_XENO_OPT_PIPE_NRDEV=32 CONFIG_XENO_OPT_REGISTRY=y CONFIG_XENO_OPT_REGISTRY_NRSLOTS=512 CONFIG_XENO_OPT_SYS_HEAPSZ=128 CONFIG_XENO_OPT_STATS=y CONFIG_XENO_OPT_DEBUG=y # CONFIG_XENO_OPT_DEBUG_QUEUES is not set CONFIG_XENO_OPT_DEBUG_BHEAP=y # CONFIG_XENO_OPT_WATCHDOG is not set # # Timing # # CONFIG_XENO_OPT_TIMING_PERIODIC is not set CONFIG_XENO_OPT_TIMING_PERIOD=0 CONFIG_XENO_OPT_TIMING_TIMERLAT=0 CONFIG_XENO_OPT_TIMING_SCHEDLAT=0 # # Scalability # # CONFIG_XENO_OPT_SCALABLE_SCHED is not set CONFIG_XENO_OPT_TIMER_LIST=y # CONFIG_XENO_OPT_TIMER_HEAP is not set # CONFIG_XENO_OPT_TIMER_WHEEL is not set # # Shared interrupts # # CONFIG_XENO_OPT_SHIRQ_LEVEL is not set # CONFIG_XENO_OPT_SHIRQ_EDGE is not set # # Machine # # # Interfaces # CONFIG_XENO_SKIN_NATIVE=y CONFIG_XENO_OPT_NATIVE_PIPE=y CONFIG_XENO_OPT_NATIVE_PIPE_BUFSZ=4096 CONFIG_XENO_OPT_NATIVE_REGISTRY=y CONFIG_XENO_OPT_NATIVE_SEM=y CONFIG_XENO_OPT_NATIVE_EVENT=y CONFIG_XENO_OPT_NATIVE_MUTEX=y CONFIG_XENO_OPT_NATIVE_COND=y CONFIG_XENO_OPT_NATIVE_QUEUE=y CONFIG_XENO_OPT_NATIVE_HEAP=y CONFIG_XENO_OPT_NATIVE_ALARM=y CONFIG_XENO_OPT_NATIVE_MPS=y # CONFIG_XENO_OPT_NATIVE_INTR is not set CONFIG_XENO_SKIN_POSIX=y # CONFIG_XENO_OPT_POSIX_SHM is not set # CONFIG_XENO_OPT_POSIX_INTR is not set # CONFIG_XENO_SKIN_PSOS is not set # CONFIG_XENO_SKIN_UITRON is not set # CONFIG_XENO_SKIN_VRTX is not set # CONFIG_XENO_SKIN_VXWORKS is not set # CONFIG_XENO_SKIN_RTAI is not set CONFIG_XENO_SKIN_RTDM=y CONFIG_XENO_OPT_RTDM_FILDES=128 # CONFIG_XENO_OPT_DEBUG_RTDM is not set # # Drivers # # # Serial drivers # # CONFIG_XENO_DRIVERS_16550A is not set # # Testing drivers # CONFIG_XENO_DRIVERS_TIMERBENCH=y # CONFIG_XENO_DRIVERS_IRQBENCH is not set CONFIG_XENO_DRIVERS_SWITCHTEST=y # # CAN drivers # # CONFIG_XENO_DRIVERS_RTCAN is not set # # Processor # # CONFIG_6xx is not set CONFIG_40x=y # CONFIG_44x is not set # CONFIG_POWER3 is not set # CONFIG_POWER4 is not set # CONFIG_8xx is not set # CONFIG_E200 is not set # CONFIG_E500 is not set # CONFIG_MATH_EMULATION is not set # CONFIG_KEXEC is not set # CONFIG_CPU_FREQ is not set CONFIG_4xx=y # CONFIG_WANT_EARLY_SERIAL is not set # # IBM 4xx options # # CONFIG_BUBINGA is not set # CONFIG_CPCI405 is not set # CONFIG_EP405 is not set
[Xenomai-core] BUG: sleeping function called from invalid context at kernel/xenomai/skins/posix/syscall.c:272
Hello,
when I start the RT-Socket-CAN program rtcan_rtt.c, I get the attached
error message. Any idea where the problem could be? It was working with
Xenomai under Linux 2.4.25.
Thanks.
Wolfgang.
bash-3.00# rtcan_rtt rtcan0 rtcan1
BUG: sleeping function called from invalid context at kernel/xenomai/skins/posix/syscall.c:272
in_atomic():0, irqs_disabled():1
Call Trace:
[C30C9E00] [C000D7E8] show_stack+0x48/0x190 (unreliable)
[C30C9E30] [C0013D08] __might_sleep+0xc4/0xf0
[C30C9E50] [C0066514] __pthread_setschedparam+0xe0/0x2c0
[C30C9EB0] [C00492AC] losyscall_event+0xc8/0x1e0
[C30C9EE0] [C003A330] __ipipe_dispatch_event+0x94/0x19c
[C30C9F30] [C0009290] __ipipe_syscall_root+0x44/0xfc
[C30C9F40] [C00041C0] DoSyscall+0x24/0x60
1 3
TX txsock=897, ifr_name=rtcan0
RX rxsock=898, ifr_name=rtcan1
Round-Trip-Time test rtcan0 - rtcan1 with CAN ID 0x1
Cycle time: 1 us
All RTT timing figures are in us.
Messages RTTlast RTT_avg RTT_min RTT_max Overruns
1001022 997 99210260
200 9981006 99010340
300 9981005 99010340
/*
* Round-Trip-Time Test - sends and receives messages and measures the
*time in between.
*
* Copyright (C) 2006 Wolfgang Grandegger [EMAIL PROTECTED]
*
* Based on RTnet's examples/xenomai/posix/rtt-sender.c.
*
* Copyright (C) 2002 Ulrich Marx [EMAIL PROTECTED]
* 2002 Marc Kleine-Budde [EMAIL PROTECTED]
* 2006 Jan Kiszka [EMAIL PROTECTED]
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*/
#include errno.h
#include mqueue.h
#include signal.h
#include pthread.h
#include stdio.h
#include stdlib.h
#include string.h
#include unistd.h
#include limits.h
#include getopt.h
#include netinet/in.h
#include sys/mman.h
#include rtdm/rtcan.h
static unsigned int cycle = 1; /* 10 ms */
static can_id_t can_id = 0x1;
static pthread_t txthread, rxthread;
static int txsock, rxsock;
static mqd_t mq;
static int txcount, rxcount;
static int overruns;
struct rtt_stat {
long long rtt;
long long rtt_min;
long long rtt_max;
long long rtt_sum;
long long rtt_sum_last;
int counts_per_sec;
};
static void print_usage(char *prg)
{
fprintf(stderr,
Usage: %s [Options] tx-can-interface rx-can-interface\n
Options:\n
-i, --id=ID CAN Identifier (default = 0x1)\n
-c, --cycle Cycle time in us (default = 1us)\n,
prg);
}
void *transmitter(void *arg)
{
struct sched_param param = { .sched_priority = 80 };
struct timespec next_period;
struct timespec time;
struct can_frame frame;
long long *rtt_time = (long long *)frame.data;
/* Pre-fill CAN frame */
frame.can_id = can_id;
frame.can_dlc = sizeof(*rtt_time);
pthread_setschedparam(pthread_self(), SCHED_FIFO, param);
clock_gettime(CLOCK_MONOTONIC, next_period);
while(1) {
next_period.tv_nsec += cycle * 1000;
if (next_period.tv_nsec = 10) {
next_period.tv_nsec = 0;
next_period.tv_sec++;
}
clock_nanosleep(CLOCK_MONOTONIC, TIMER_ABSTIME, next_period, NULL);
if (rxcount != txcount) {
overruns++;
continue;
}
clock_gettime(CLOCK_MONOTONIC, time);
*rtt_time = time.tv_sec * 10LL + time.tv_nsec;
/* Transmit the message containing the local time */
if (send(txsock, (void *)frame, sizeof(can_frame_t), 0) 0) {
if (errno == EBADF)
printf(terminating transmitter thread\n);
else
perror(send failed);
return NULL;
}
txcount++;
}
}
void *receiver(void *arg)
{
struct sched_param param = { .sched_priority = 82 };
struct timespec time;
struct can_frame frame;
long long *rtt_time = (long long *)frame.data;
struct rtt_stat rtt_stat = {0, LONG_LONG_MAX, LONG_LONG_MIN, 0, 0, 0};
pthread_setschedparam(pthread_self(), SCHED_FIFO, param);
rtt_stat.counts_per_sec = 100 / cycle;
while (1) {
if (recv(rxsock, (void *)frame, sizeof(can_frame_t), 0) 0) {
if (errno == EBADF)
printf(terminating receiver thread\n);
else
perror(recv failed);
return NULL;
}
clock_gettime(CLOCK_MONOTONIC, time);
if (rxcount++ 0
Re: [Xenomai-core] BUG: sleeping function called from invalid context at kernel/xenomai/skins/posix/syscall.c:272
Jan Kiszka wrote: Wolfgang Grandegger wrote: Hello, when I start the RT-Socket-CAN program rtcan_rtt.c, I get the attached error message. Any idea where the problem could be? It was working with Xenomai under Linux 2.4.25. Thanks. Wolfgang. bash-3.00# rtcan_rtt rtcan0 rtcan1 BUG: sleeping function called from invalid context at kernel/xenomai/skins/posix/syscall.c:272 in_atomic():0, irqs_disabled():1 Leaking lock somewhere? Some suggestions: - Does it also happen with rtcan_virt? - If no: switch on XENO_OPT_DEBUG and then XENO_OPT_DEBUG_RTDM (may catch leaking locks of the CAN driver) - If yes: what arch are you on? PPC? On x86/2.6 I do not have problems with your demo over rtcan_virt. Thanks for the hints. I will continue testing later today on my MPC5200 (PPC). Wolfgang. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] BUG: sleeping function called from invalid context at kernel/xenomai/skins/posix/syscall.c:272
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
Hello,
when I start the RT-Socket-CAN program rtcan_rtt.c, I get the attached
error message. Any idea where the problem could be? It was working with
Xenomai under Linux 2.4.25.
Thanks.
Wolfgang.
bash-3.00# rtcan_rtt rtcan0 rtcan1
BUG: sleeping function called from invalid context at
kernel/xenomai/skins/posix/syscall.c:272
in_atomic():0, irqs_disabled():1
Leaking lock somewhere? Some suggestions:
- Does it also happen with rtcan_virt?
Yes.
- If no: switch on XENO_OPT_DEBUG and then XENO_OPT_DEBUG_RTDM (may
catch leaking locks of the CAN driver)
Does not give an additional information for the if yes case.
- If yes: what arch are you on? PPC? On x86/2.6 I do not have problems
with your demo over rtcan_virt.
It's on PowerPC (MPC5200) under Linux 2.6. I have not realized a similar
problem with 2.4 on the same board. And it seems to be related with
pthread_setschedparam(). And is nothing to do with RTCAN as the
cyclictest() prints the same error message. There is obviously a problem
with __xn_put_user - __put_user - put_user_nocheck:
#define __put_user_nocheck(x, ptr, size)\
({ \
long __pu_err; \
__typeof__(*(ptr)) __user *__pu_addr = (ptr); \
if (!is_kernel_addr((unsigned long)__pu_addr)) \
might_sleep(); \
__chk_user_ptr(ptr);\
__put_user_size((x), __pu_addr, (size), __pu_err); \
__pu_err; \
})
The might_sleep seems to make trouble, which showed up in recent
versions of Linux on the PowerPC arch :-(.
Wolfgang.
Wolfgang.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [PATCH] fixing __xn_put_user and __xn_get_user for PowerPC
Hello,
the attached patch fixes the problem described in the mail
https://mail.gna.org/public/xenomai-core/2006-10/msg00037.html. Here is
the ChangeLog entry:
* include/asm-powerpc/wrappers.h, include/asm-powerpc/syscall.h:
Since Linux 2.4.15, __put_user and __get_user call migth_sleep.
To avoid that, wrapper functions have been added.
Wolfgang.
Index: include/asm-powerpc/syscall.h
===
--- include/asm-powerpc/syscall.h (revision 1733)
+++ include/asm-powerpc/syscall.h (working copy)
@@ -57,8 +57,8 @@
({ int __err__ = __copy_from_user_inatomic(dstP,srcP,n); __err__; })
#define __xn_copy_to_user(task,dstP,srcP,n) \
({ int __err__ = __copy_to_user_inatomic(dstP,srcP,n); __err__; })
-#define __xn_put_user(task,src,dstP) __put_user(src,dstP)
-#define __xn_get_user(task,dst,srcP) __get_user(dst,srcP)
+#define __xn_put_user(task,src,dstP) wrap_put_user(src,dstP)
+#define __xn_get_user(task,dst,srcP) wrap_get_user(dst,srcP)
#define __xn_strncpy_from_user(task,dstP,srcP,n)__strncpy_from_user(dstP,srcP,n)
#define __xn_access_ok(task,type,addr,size) wrap_range_ok(task,addr,size)
Index: include/asm-powerpc/wrappers.h
===
--- include/asm-powerpc/wrappers.h (revision 1733)
+++ include/asm-powerpc/wrappers.h (working copy)
@@ -49,4 +49,38 @@
#endif /* LINUX_VERSION_CODE KERNEL_VERSION(2,5,0) */
+#if LINUX_VERSION_CODE KERNEL_VERSION(2,6,15)
+
+#define wrap_put_user(src,dstP) __put_user(src,dstP)
+#define wrap_get_user(dst,srcP) __get_user(dst,srcP)
+
+#else /* LINUX_VERSION_CODE KERNEL_VERSION(2,6,15) */
+
+/* from linux/include/asm-powerpc/uaccess.h */
+#define wrap_get_user(x, ptr) \
+({\
+ int __gu_size = sizeof(*(ptr));\
+ long __gu_err; \
+ unsigned long __gu_val; \
+ const __typeof__(*(ptr)) __user *__gu_addr = (ptr); \
+ __chk_user_ptr(ptr); \
+ __get_user_size(__gu_val, __gu_addr, gu_size, __gu_err);\
+ (x) = (__typeof__(*(ptr)))__gu_val; \
+ __gu_err; \
+})
+
+#define wrap_put_user(x, ptr) \
+({\
+ int __pu_size = sizeof(*(ptr));\
+ long __pu_err; \
+ __typeof__(*(ptr)) __user *__pu_addr = (ptr); \
+ __chk_user_ptr(ptr); \
+ __put_user_size((__typeof__(*(ptr)))(x), \
+ __pu_addr, __pu_size, __pu_err); \
+ __pu_err; \
+})
+
+#endif /* LINUX_VERSION_CODE KERNEL_VERSION(2,6,15) */
+
+
#endif /* _XENO_ASM_POWERPC_WRAPPERS_H */
Index: ChangeLog
===
--- ChangeLog (revision 1733)
+++ ChangeLog (working copy)
@@ -1,3 +1,9 @@
+2006-10-19 Wolfgang Grandegger [EMAIL PROTECTED]
+
+ * include/asm-powerpc/wrappers.h, include/asm-powerpc/syscall.h:
+ Since Linux 2.4.15, __put_user and __get_user call migth_sleep.
+ To avoid that, wrapper functions have been added.
+
2006-10-18 Jan Kiszka [EMAIL PROTECTED]
* configure.in, scripts/xeno-config.in: Reducing CFLAGS and LDFLAGS
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] switchtest FPU register error on PPC 2.6.18
Hello, I just realized the error message: Error after context switch from task 8(rtup-8) to task 10(rtup_ufpp-10), FPU registers were set to 1000 (maybe task sleeper_ufps-0) when running switchtest on an PPC under Linux 2.6.18 with Xenomai head of SVN. I have attached the full output log. Can some tell me what went exactly wrong and where I should start looking at? Thanks. Wolfgang. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] switchtest FPU register error on PPC 2.6.18
Gilles Chanteperdrix wrote: Wolfgang Grandegger wrote: Hello, I just realized the error message: Error after context switch from task 8(rtup-8) to task 10(rtup_ufpp-10), FPU registers were set to 1000 (maybe task sleeper_ufps-0) when running switchtest on an PPC under Linux 2.6.18 with Xenomai head of SVN. I have attached the full output log. Are you sure you did ? Oh, well, ... see attachment. Can some tell me what went exactly wrong and where I should start looking at? It means that after a switch from task 8 to task 10, the FPU context is the one of task 0. So, some context switches which should have switched the FPU did not. If you are lucky, you should get this error systematically. In order to investigate, you should try and reduce the number of tasks created by switchtest. switchtest --help will tell you the list of tasks created by switchtest by default, start from this list, and try removing some tasks, keeping the failure. When you have the minimum set of tasks that create the failure, try to trace the fpu switches, to see which one does not do its job correctly. OK, thanks for the hint. I forgot to mention that it only happens once after reboot. Re-exectution does not show the error any more. Wolfgang. bash-3.00# cd xenomai/testsuite/switchtest/ bash-3.00# ./run * * * Type ^C to stop this application. * * == Testing FPU check routines... r0: 1 != 2 r1: 1 != 2 r2: 1 != 2 r3: 1 != 2 r4: 1 != 2 r5: 1 != 2 r6: 1 != 2 r7: 1 != 2 r8: 1 != 2 r9: 1 != 2 r10: 1 != 2 r11: 1 != 2 r12: 1 != 2 r13: 1 != 2 r14: 1 != 2 r15: 1 != 2 r16: 1 != 2 r17: 1 != 2 r18: 1 != 2 r19: 1 != 2 r20: 1 != 2 r21: 1 != 2 r22: 1 != 2 r23: 1 != 2 r24: 1 != 2 r25: 1 != 2 r26: 1 != 2 r27: 1 != 2 r28: 1 != 2 r29: 1 != 2 r30: 1 != 2 r31: 1 != 2 == FPU check routines: OK. == Threads: sleeper_ufps-0 rtk-1 rtk-2 rtk_fp-3 rtk_fp-4 rtk_fp_ufpp-5 rtk_fp_ufpp-6 rtup-7 rtup-8 rtup_ufpp-9 rtup_ufpp-10 rtus-11 rtus-12 rtus_ufps-13 rtus_ufps-14 rtuo-15 rtuo-16 rtuo_ufpp-17 rtuo_ufpp-18 rtuo_ufps-19 rtuo_ufps-20 rtuo_ufpp_ufps-21 rtuo_ufpp_ufps-22 r0: 1000 != 10 r1: 1000 != 10 r2: 1000 != 10 r3: 1000 != 10 r4: 1000 != 10 r5: 1000 != 10 r6: 1000 != 10 r7: 1000 != 10 r8: 1000 != 10 r9: 1000 != 10 r10: 1000 != 10 r11: 1000 != 10 r12: 1000 != 10 r13: 1000 != 10 r14: 1000 != 10 r15: 1000 != 10 r16: 1000 != 10 r17: 1000 != 10 r18: 1000 != 10 r19: 1000 != 10 r20: 1000 != 10 r21: 1000 != 10 r22: 1000 != 10 r23: 1000 != 10 r24: 1000 != 10 r25: 1000 != 10 r26: 1000 != 10 r27: 1000 != 10 r28: 1000 != 10 r29: 1000 != 10 r30: 1000 != 10 r31: 1000 != 10 Error after context switch from task 8(rtup-8) to task 10(rtup_ufpp-10), FPU registers were set to 1000 (maybe task sleeper_ufps-0) RTT| 00:00:00 RTH|ctx switches|---total RTD| 28| 28___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] 2.6.18 ppc ipipe patch patch
Paul wrote:
Currently have a G3 Mac on loan and thought it worth trying out a 2.6.18.1
kernel - The prepare-kernel.sh patched without any errors, a few offset lines,
but that is to be expected.. Once configured however, compilation failed with
some fatal errors over ipipe.h and line 223 - It would appear that the
adeos-ipipe patch is adding a malformed line from the preamble of the
following chunk. The ppc-ipipe_fix patch corrects this issue, and the second
attempts to clean up the rest of the patch.
Thanks for the fix. Did it work then? Note that this patch only supports
systems in the arch/ppc tree (and not in the arch/powerpc tree).
Wolfgang,
Regards, Paul.
Index: ksrc/arch/powerpc/patches/adeos-ipipe-2.6.18-ppc-1.4-01.patch
===
--- ksrc/arch/powerpc/patches/adeos-ipipe-2.6.18-ppc-1.4-01.patch
(revision 1732)
+++ ksrc/arch/powerpc/patches/adeos-ipipe-2.6.18-ppc-1.4-01.patch
(working copy)
@@ -1,4 +1,4 @@
-+ diff -u linux-2.6.18/arch/powerpc/kernel/idle.c.ORIG
linux-2.6.18/arch/powerpc/kernel/idle.c
+diff -u linux-2.6.18/arch/powerpc/kernel/idle.c.ORIG
linux-2.6.18/arch/powerpc/kernel/idle.c
--- linux-2.6.18/arch/powerpc/kernel/idle.c.ORIG 2006-09-20
05:42:06.0 +0200
+++ linux-2.6.18/arch/powerpc/kernel/idle.c2006-09-30 10:14:30.845052232
+0200
@@ -51,6 +51,7 @@
@@ -31,7 +31,7 @@
set_thread_flag(TIF_POLLING_NRFLAG);
} else {
-+ diff -u linux-2.6.18/arch/powerpc/kernel/irq.c.ORIG
linux-2.6.18/arch/powerpc/kernel/irq.c
+diff -u linux-2.6.18/arch/powerpc/kernel/irq.c.ORIG
linux-2.6.18/arch/powerpc/kernel/irq.c
--- linux-2.6.18/arch/powerpc/kernel/irq.c.ORIG2006-09-20
05:42:06.0 +0200
+++ linux-2.6.18/arch/powerpc/kernel/irq.c 2006-09-24 20:35:04.0
+0200
@@ -68,7 +68,11 @@
@@ -46,7 +46,7 @@
#ifdef CONFIG_PPC32
EXPORT_SYMBOL(__irq_offset_value);
-+ diff -u linux-2.6.18/arch/ppc/Kconfig.ORIG linux-2.6.18/arch/ppc/Kconfig
+diff -u linux-2.6.18/arch/ppc/Kconfig.ORIG linux-2.6.18/arch/ppc/Kconfig
--- linux-2.6.18/arch/ppc/Kconfig.ORIG 2006-09-20 05:42:06.0 +0200
+++ linux-2.6.18/arch/ppc/Kconfig 2006-09-24 14:02:26.0 +0200
@@ -950,6 +950,8 @@
@@ -58,7 +58,7 @@
config HIGHMEM
bool High memory support
-+ diff -u linux-2.6.18/arch/ppc/kernel/entry.S.ORIG linux-2.6.18/arch/ppc/kernel/entry.S
+diff -u linux-2.6.18/arch/ppc/kernel/entry.S.ORIG
linux-2.6.18/arch/ppc/kernel/entry.S
--- linux-2.6.18/arch/ppc/kernel/entry.S.ORIG 2006-09-20 05:42:06.0
+0200
+++ linux-2.6.18/arch/ppc/kernel/entry.S 2006-09-30 10:11:25.664204000
+0200
@@ -132,8 +132,23 @@
@@ -204,7 +204,7 @@
+bne+ ret_from_except
+b restore
+#endif /* CONFIG_IPIPE */
-+ diff -u linux-2.6.18/arch/ppc/kernel/head_44x.S.ORIG
linux-2.6.18/arch/ppc/kernel/head_44x.S
+diff -u linux-2.6.18/arch/ppc/kernel/head_44x.S.ORIG
linux-2.6.18/arch/ppc/kernel/head_44x.S
--- linux-2.6.18/arch/ppc/kernel/head_44x.S.ORIG 2006-09-20
05:42:06.0 +0200
+++ linux-2.6.18/arch/ppc/kernel/head_44x.S2006-09-24 14:02:26.0
+0200
@@ -427,7 +427,11 @@
@@ -220,7 +220,7 @@
/* Alignment Interrupt */
ALIGNMENT_EXCEPTION
-+ diff -u linux-2.6.18/arch/ppc/kernel/head_4xx.S.ORIG
linux-2.6.18/arch/ppc/kernel/head_4xx.S
+diff -u linux-2.6.18/arch/ppc/kernel/head_4xx.S.ORIG
linux-2.6.18/arch/ppc/kernel/head_4xx.S
--- linux-2.6.18/arch/ppc/kernel/head_4xx.S.ORIG 2006-09-20
05:42:06.0 +0200
+++ linux-2.6.18/arch/ppc/kernel/head_4xx.S2006-09-24 14:02:26.0
+0200
@@ -228,6 +228,12 @@
@@ -260,7 +260,7 @@
#if 0
/* NOTE:
-+ diff -u linux-2.6.18/arch/ppc/kernel/head_8xx.S.ORIG
linux-2.6.18/arch/ppc/kernel/head_8xx.S
+diff -u linux-2.6.18/arch/ppc/kernel/head_8xx.S.ORIG
linux-2.6.18/arch/ppc/kernel/head_8xx.S
--- linux-2.6.18/arch/ppc/kernel/head_8xx.S.ORIG 2006-09-20
05:42:06.0 +0200
+++ linux-2.6.18/arch/ppc/kernel/head_8xx.S2006-09-24 14:02:26.0
+0200
@@ -186,6 +186,11 @@
@@ -299,7 +299,7 @@
EXCEPTION(0xa00, Trap_0a, unknown_exception, EXC_XFER_EE)
EXCEPTION(0xb00, Trap_0b, unknown_exception, EXC_XFER_EE)
-+ diff -u linux-2.6.18/arch/ppc/kernel/head_booke.h.ORIG
linux-2.6.18/arch/ppc/kernel/head_booke.h
+diff -u linux-2.6.18/arch/ppc/kernel/head_booke.h.ORIG
linux-2.6.18/arch/ppc/kernel/head_booke.h
--- linux-2.6.18/arch/ppc/kernel/head_booke.h.ORIG 2006-09-20
05:42:06.0 +0200
+++ linux-2.6.18/arch/ppc/kernel/head_booke.h 2006-09-24 14:02:26.0
+0200
@@ -187,6 +187,12 @@
@@ -339,7 +339,7 @@
#define FP_UNAVAILABLE_EXCEPTION \
START_EXCEPTION(FloatingPointUnavailable) \
-+ diff -u linux-2.6.18/arch/ppc/kernel/head_fsl_booke.S.ORIG
Re: [Xenomai-core] [PATCH] prepare-kernel.sh breaks linux-2.4 drivers/Makefile
Andrew Dennison wrote: Running prepare-kernel on the denx 2.4 kernel adds the following line mod-subdirs := xenomai This prevents all other mod-subdirs under drivers from building. What does not build. Non-Xenomai drivers as modules? Patch is against r1273 but still seems to apply (and be required) on head. Going to check it soon. Thanks. Wolfgang. Andrew diff --git a/scripts/prepare-kernel.sh b/scripts/prepare-kernel.sh index fbc91ce..ca87e7f 100755 --- a/scripts/prepare-kernel.sh +++ b/scripts/prepare-kernel.sh @@ -455,7 +455,7 @@ EOF patch_ed drivers/Makefile EOF /include \$(TOPDIR)\/Rules.make i -mod-subdirs := xenomai +mod-subdirs += xenomai subdir-\$(CONFIG_XENOMAI) += xenomai . ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] prepare-kernel.sh breaks linux-2.4 drivers/Makefile
Wolfgang Grandegger wrote: Andrew Dennison wrote: Running prepare-kernel on the denx 2.4 kernel adds the following line mod-subdirs := xenomai This prevents all other mod-subdirs under drivers from building. What does not build. Non-Xenomai drivers as modules? Patch is against r1273 but still seems to apply (and be required) on head. Going to check it soon. It's obviously a bug and could cause modules not to get build under certain conditions. I was just wondering why I have not already realized it in the past. Thanks. Wolfgang. Thanks. Wolfgang. Andrew diff --git a/scripts/prepare-kernel.sh b/scripts/prepare-kernel.sh index fbc91ce..ca87e7f 100755 --- a/scripts/prepare-kernel.sh +++ b/scripts/prepare-kernel.sh @@ -455,7 +455,7 @@ EOF patch_ed drivers/Makefile EOF /include \$(TOPDIR)\/Rules.make i -mod-subdirs := xenomai +mod-subdirs += xenomai subdir-\$(CONFIG_XENOMAI) += xenomai . ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Buildbot finds unresolved symbols `xnarch_atomic_xchg'
Hi Niklaus, Niklaus Giger wrote: Hi I see the following failure since revision 1771. e.g. http://ngiger.dyndns.org/buildbot-full/ppc_f/builds/56/step-mk_kernel/1 kernel/built-in.o: In function `xnintr_irq_handler': intr.c:(.text+0x34334): undefined reference to `xnarch_atomic_xchg' intr.c:(.text+0x34424): undefined reference to `xnarch_atomic_xchg' kernel/built-in.o: In function `xnpod_schedule': (.text+0x38470): undefined reference to `xnarch_atomic_xchg' kernel/built-in.o: In function `xnpod_schedule_runnable': (.text+0x39f28): undefined reference to `xnarch_atomic_xchg' kernel/built-in.o: In function `xnpod_init': (.text+0x3a770): undefined reference to `xnarch_atomic_xchg' make: *** [.tmp_vmlinux1] Fehler 1 I lost track somehow. What version of the Linux kernel, ADEOS-IPIPE and Xenomai are you using? Thanks. Wolfgang. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Bug in taskSuspend for user mode vxworks
Niklaus Giger wrote: Am Montag, 30. Oktober 2006 08:31 schrieb Wolfgang Grandegger: Niklaus Giger wrote: Am Samstag, 28. Oktober 2006 20:36 schrieb Wolfgang Grandegger: Niklaus Giger wrote: Am Samstag, 28. Oktober 2006 14:54 schrieb Niklaus Giger: Am Freitag, 27. Oktober 2006 18:38 schrieb Philippe Gerum: On Wed, 2006-10-25 at 23:46 +0200, Niklaus Giger wrote: Hi My impression from our last discussion was that your toolchain is somehow broken as I was unable to reproduce your problems on (almost) the same hardware I think I really have to reactivate my old Walnut board to have common platform to test with Wolfgang Grandegger. It would make more sense to use the ELDK4 for comparison. I don't think it depends on the hardware. As I forced my son to run on his MacMini (Intel Core Duo) only Linux and no MacOsX (he discovered widelands and was quite happy), I had a platform where I could install the CD with ELDK 4.0, which I had laying around. After some setting up of my environment and tweaking my scripts to work with ELDK (e.g. adding --host=ppc CC=ppc_4xx-gcc to my xenomai/configure) I ended --host=ppc-linux is already enough with CROSS_COMPILE=ppc_4xx- set. up with a nice environment and rootfs with much more precompiled programs than I had ever before. Debugging on the platform is now as good as on my PowerBook. My situation is now as follows: - ELDK 4.0 installed on Debian Etch MacMini - Using ELD 4.0 rootfs ppc_4xx - compiled the kernel uImage, modules, xenomai using ppc_4xx-gcc (but NOT adding any -mcpu=40x flag to the compiler) The trap 0 in /proc/xenomai/fault seems to count on each invocation of simple 0: 51(Data or instruction access) gdb however no does not show anything abnormal, as it says now This GDB was configured as ppc-linux...Using host libthread_db library /lib/tls/libthread_db.so.1. (gdb) run Starting program: /bin/simple [Thread debugging using libthread_db enabled] [New Thread 805422032 (LWP 639)] root_thread_init 4[New Thread 805455088 (LWP 642)] Program exited normally. (gdb) quit Though I am still puzzled. Could you please send me your Makefile or the compile command to make simple, then I would give it a try on my setup. Here are the commands ppc_4xx-gcc -I../.. -I/home/hcu/rootfs/usr/xenomai/include -D_GNU_SOURCE -D_REENTRANT -I/net/ng/mnt/data.ng/hcu/project/vx_skin -D__XENO__ -g -DVXWORKS-c -o simple.o simple.c ppc_4xx-gcc -o simple simple.o -L/home/hcu/rootfs/usr/xenomai/lib -lpthread -lvxworks Again the same question. What versions of kernel, ADEOS-IPIPE and Xenomai are you using.I have some problems to get the kernel booted with the VxWorks skin emulation. I understood, that I must build the Native and POSIX skin as modules and enable the periodic timer support with a resonable frequency. Wolfgang. Thanks for your help. Will be busy till tomorrow evening. Best regards ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Bug in taskSuspend for user mode vxworks
Niklaus Giger wrote: Am Dienstag, 31. Oktober 2006 09:14 schrieb Wolfgang Grandegger: Niklaus Giger wrote: Am Montag, 30. Oktober 2006 08:31 schrieb Wolfgang Grandegger: Niklaus Giger wrote: Am Samstag, 28. Oktober 2006 20:36 schrieb Wolfgang Grandegger: Niklaus Giger wrote: Am Samstag, 28. Oktober 2006 14:54 schrieb Niklaus Giger: Am Freitag, 27. Oktober 2006 18:38 schrieb Philippe Gerum: On Wed, 2006-10-25 at 23:46 +0200, Niklaus Giger wrote: Hi My impression from our last discussion was that your toolchain is somehow broken as I was unable to reproduce your problems on (almost) the same hardware I think I really have to reactivate my old Walnut board to have common platform to test with Wolfgang Grandegger. It would make more sense to use the ELDK4 for comparison. I don't think it depends on the hardware. As I forced my son to run on his MacMini (Intel Core Duo) only Linux and no MacOsX (he discovered widelands and was quite happy), I had a platform where I could install the CD with ELDK 4.0, which I had laying around. After some setting up of my environment and tweaking my scripts to work with ELDK (e.g. adding --host=ppc CC=ppc_4xx-gcc to my xenomai/configure) I ended --host=ppc-linux is already enough with CROSS_COMPILE=ppc_4xx- set. up with a nice environment and rootfs with much more precompiled programs than I had ever before. Debugging on the platform is now as good as on my PowerBook. My situation is now as follows: - ELDK 4.0 installed on Debian Etch MacMini - Using ELD 4.0 rootfs ppc_4xx - compiled the kernel uImage, modules, xenomai using ppc_4xx-gcc (but NOT adding any -mcpu=40x flag to the compiler) The trap 0 in /proc/xenomai/fault seems to count on each invocation of simple 0: 51(Data or instruction access) gdb however no does not show anything abnormal, as it says now This GDB was configured as ppc-linux...Using host libthread_db library /lib/tls/libthread_db.so.1. (gdb) run Starting program: /bin/simple [Thread debugging using libthread_db enabled] [New Thread 805422032 (LWP 639)] root_thread_init 4[New Thread 805455088 (LWP 642)] Program exited normally. (gdb) quit Though I am still puzzled. Could you please send me your Makefile or the compile command to make simple, then I would give it a try on my setup. Here are the commands ppc_4xx-gcc -I../.. -I/home/hcu/rootfs/usr/xenomai/include -D_GNU_SOURCE -D_REENTRANT -I/net/ng/mnt/data.ng/hcu/project/vx_skin -D__XENO__ -g -DVXWORKS-c -o simple.o simple.c ppc_4xx-gcc -o simple simple.o -L/home/hcu/rootfs/usr/xenomai/lib -lpthread -lvxworks Again the same question. What versions of kernel, ADEOS-IPIPE and Xenomai are you using.I have some problems to get the kernel booted with the VxWorks skin emulation. I understood, that I must build the Native and POSIX skin as modules and enable the periodic timer support with a resonable frequency. I used revision 1747 of the xenomai trunk, linux 2.4.17 + some small patches (attached) for my system, the attached .config, adeos-ipipe-2.6.14-ppc-1.5-01.patch. I have vxworks built-in to enforce that the timers get initialized into the periodic mode. OK, with a similar setup I get the same results as you have seen on your (son's) MacMini. I have attached the output. Wolfgang. sh-3.00# export LD_LIBRARY_PATH=/home/wolf/xenomai/lib bash-3.00# ./simple root_thread_init 3 bash-3.00# cat /proc/xenomai/faults TRAP CPU0 0:1(Data or instruction access) 1:0(Alignment) 2:0(Altivec unavailable) 3:0(Program check exception) 4:0(Machine check exception) 5:0(Unknown) 6:0(Instruction breakpoint) 7:0(Run mode exception) 8:0(Single-step exception) 9:0(Non-recoverable exception) 10:0(Software emulation) 11:0(Debug) 12:0(SPE) 13:0(Altivec assist) bash-3.00# ./simple root_thread_init 3 bash-3.00# cat /proc/xenomai/faults TRAP CPU0 0:2(Data or instruction access) 1:0(Alignment) 2:0(Altivec unavailable) 3:0(Program check exception) 4:0(Machine check exception) 5:0(Unknown) 6:0(Instruction breakpoint) 7:0(Run mode exception) 8:0(Single-step exception) 9:0(Non-recoverable exception) 10:0(Software emulation) 11:0(Debug) 12:0(SPE) 13:0(Altivec assist) bash-3.00# gdb simple GNU gdb Red Hat Linux (6.3.0.0-1.21_1rh) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions
[Xenomai-core] [PATCH] Doxygen hyperlinking utilitiy and demo programs
Hello,
the attached patch adds the RT-Socket-CAN utility programs as examples
to the Doxygen documentation setup. This creates some nice cross
reference from the documented API functions to the example code lines
and vice versa. In a similar way, the Xenomai demo programs and code
snippets could be integrated making it much easier to find example code
or the description of an API function used in an example.
Please have a look and comment?
Thanks.
Wolfgang.
Index: include/rtdm/rtcan.h
===
--- include/rtdm/rtcan.h (revision 1810)
+++ include/rtdm/rtcan.h (working copy)
@@ -1116,7 +1116,15 @@
/** @} */
+/*!
+ * @anchor Utilities @name CAN test and utility functions
+ * @{ */
+/** @example rtcanconfig.c */
+/** @example rtcansend.c */
+/** @example rtcanrecv.c */
/** @} */
+/** @} */
+
#endif /* _RTCAN_H */
Index: doc/doxygen/Doxyfile-common.in
===
--- doc/doxygen/Doxyfile-common.in (revision 1810)
+++ doc/doxygen/Doxyfile-common.in (working copy)
@@ -383,27 +383,27 @@
# EXCLUDE_PATTERNS tag to specify one or more wildcard patterns to exclude
# certain files from those directories.
-EXCLUDE_PATTERNS =
+EXCLUDE_PATTERNS = *.c
# The EXAMPLE_PATH tag can be used to specify one or more files or
# directories that contain example code fragments that are included (see
# the \include command).
-EXAMPLE_PATH =
+EXAMPLE_PATH = ../../src/utils
# If the value of the EXAMPLE_PATH tag contains directories, you can use the
# EXAMPLE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp
# and *.h) to filter out the source-files in the directories. If left
# blank all files are included.
-EXAMPLE_PATTERNS =
+EXAMPLE_PATTERNS =
# If the EXAMPLE_RECURSIVE tag is set to YES then subdirectories will be
# searched for input files to be used with the \include or \dontinclude
# commands irrespective of the value of the RECURSIVE tag.
# Possible values are YES and NO. If left blank NO is used.
-EXAMPLE_RECURSIVE = NO
+EXAMPLE_RECURSIVE = YES
# The IMAGE_PATH tag can be used to specify one or more files or
# directories that contain image that are included in the documentation (see
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Doxygen hyperlinking utilitiy and demo programs
Gilles Chanteperdrix wrote: Wolfgang Grandegger wrote: Hello, the attached patch adds the RT-Socket-CAN utility programs as examples to the Doxygen documentation setup. This creates some nice cross reference from the documented API functions to the example code lines and vice versa. In a similar way, the Xenomai demo programs and code snippets could be integrated making it much easier to find example code or the description of an API function used in an example. Please have a look and comment? This is a good idea. The native skin snippets were created with the same idea in mind, it looks like I somehow forgot to finish the work. Now, about your patch, will not this hunk break some things ? # EXCLUDE_PATTERNS tag to specify one or more wildcard patterns to exclude # certain files from those directories. -EXCLUDE_PATTERNS = +EXCLUDE_PATTERNS = *.c Oops, of course, I wanted to set EXAMPLE_PATTERNS and not EXCLUDE_PATTERNS to refine the selection of example files. Thanks. Wolfgang. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [PATCH] RT-Socket-CAN, TX loopback and further improvements
Hi Jan, attached is a patch implementing the TX loopback, apart from some other fixes and improvements. The TX loopback to foreign local sockets allows to have a net-alike behavior of the CAN bus. Local sockets listening to a device can receive TX messages as well. As discussed, the TX lookback is performed when TX is done (TX done interrupt). As I still think that it will not be used very often, I made it a configurable kernel option. When it's selected, it's _on_ by default and it can be switched off or on again with setsockopt() (to make the Linux Socket-CAN people happy). As long as it's not enabled, it adds little overhead to the driver. If you have no objections I will check it in. Here is the ChangeLog entry: 2006-11-14 Wolfgang Grandegger [EMAIL PROTECTED] * ksrc/drivers/can/rtcan_dev.h, ksrc/drivers/can/rtcan_socket.h, ksrc/drivers/can/rtcan_socket.c, ksrc/drivers/can/rtcan_raw.c, ksrc/drivers/can/rtcan_modules.c, ksrc/drivers/can/sja1000/rtcan_sja1000.c, ksrc/drivers/can/mscan/rtcan_mscan.c, ksrc/drivers/can/Kconfig, ksrc/drivers/can/Config.in, src/utils/can/rtcansend.c, include/rtdm/rtcan.h,: Add feature TX loopback to local sockets. * ksrc/drivers/can/rtcan_raw.c, include/rtdm/rtcan.h: Remove locks for the setting and reading of the RX and TX timeout values and add a warning to the documentation. * src/utils/rtcansend.c: use sendto() by default to avoid binding a default filter and add option -s for using bind() and send(). * src/utils/rtcanrecv.c: add option -R for relative timestamps. * ksrc/drivers/can/rtcan_internal.h: use now RTCAN_ASSERT macros when CONFIG_XENO_DRIVERS_RTCAN_DEBUG is set. * ksrc/drivers/can/mscan/Kconfig, ksrc/drivers/can/sja1000/Kconfig, ksrc/drivers/can/Kconfig: add more help for kernel parameters. Thanks. Wolfgang. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] RT-Socket-CAN, TX loopback and further improvements
Attached is the missing patch! Wolfgang Grandegger wrote: Hi Jan, attached is a patch implementing the TX loopback, apart from some other fixes and improvements. The TX loopback to foreign local sockets allows to have a net-alike behavior of the CAN bus. Local sockets listening to a device can receive TX messages as well. As discussed, the TX lookback is performed when TX is done (TX done interrupt). As I still think that it will not be used very often, I made it a configurable kernel option. When it's selected, it's _on_ by default and it can be switched off or on again with setsockopt() (to make the Linux Socket-CAN people happy). As long as it's not enabled, it adds little overhead to the driver. If you have no objections I will check it in. Here is the ChangeLog entry: 2006-11-14 Wolfgang Grandegger [EMAIL PROTECTED] * ksrc/drivers/can/rtcan_dev.h, ksrc/drivers/can/rtcan_socket.h, ksrc/drivers/can/rtcan_socket.c, ksrc/drivers/can/rtcan_raw.c, ksrc/drivers/can/rtcan_modules.c, ksrc/drivers/can/sja1000/rtcan_sja1000.c, ksrc/drivers/can/mscan/rtcan_mscan.c, ksrc/drivers/can/Kconfig, ksrc/drivers/can/Config.in, src/utils/can/rtcansend.c, include/rtdm/rtcan.h,: Add feature TX loopback to local sockets. * ksrc/drivers/can/rtcan_raw.c, include/rtdm/rtcan.h: Remove locks for the setting and reading of the RX and TX timeout values and add a warning to the documentation. * src/utils/rtcansend.c: use sendto() by default to avoid binding a default filter and add option -s for using bind() and send(). * src/utils/rtcanrecv.c: add option -R for relative timestamps. * ksrc/drivers/can/rtcan_internal.h: use now RTCAN_ASSERT macros when CONFIG_XENO_DRIVERS_RTCAN_DEBUG is set. * ksrc/drivers/can/mscan/Kconfig, ksrc/drivers/can/sja1000/Kconfig, ksrc/drivers/can/Kconfig: add more help for kernel parameters. Thanks. Wolfgang. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core Index: include/rtdm/rtcan.h === --- include/rtdm/rtcan.h (revision 1834) +++ include/rtdm/rtcan.h (working copy) @@ -120,6 +120,7 @@ * - Level @b SOL_CAN_RAW : CAN RAW protocol (see @ref CAN_PROTO_RAW) * - Option @ref CAN_RAW_FILTER : CAN filter list * - Option @ref CAN_RAW_ERR_FILTER : CAN error mask + * - Option @ref CAN_RAW_TX_LOOPBACK : CAN TX loopback to local sockets * . * . * @n @@ -543,11 +544,9 @@ * - -EFAULT (It was not possible to access user space memory area at the *specified address.) * - -ENOMEM (Not enough memory to fulfill the operation) - * - -EINVAL (Invalid address family, or invalid length of address structure) - * - -ENODEV (Invalid CAN interface index) - * - -EBADF (Socket is about to be closed) - * - -EAGAIN (Too many receivers. Old binding (if any) is still active. - *Close some sockets and try again.) + * - -EINVAL (Invalid length optlen) + * - -ENOSPC (No space to store filter list, check RT-Socket-CAN kernel + *parameters) * . */ #define CAN_RAW_FILTER 0x1 @@ -577,16 +576,39 @@ * Specific return values: * - -EFAULT (It was not possible to access user space memory area at the *specified address.) - * - -ENOMEM (Not enough memory to fulfill the operation) - * - -EINVAL (Invalid address family, or invalid length of address structure) - * - -ENODEV (Invalid CAN interface index) - * - -EBADF (Socket is about to be closed) - * - -EAGAIN (Too many receivers. Old binding (if any) is still active. - *Close some sockets and try again.) + * - -EINVAL (Invalid length optlen) * . */ #define CAN_RAW_ERR_FILTER 0x2 +/** + * CAN TX loopback + * + * The TX loopback to other local sockets can be selected with this + * @c setsockopt. + * + * @note The TX loopback feature must be enabled in the kernel and then + * the loopback to other local TX sockets is enabled by default. + * + * @n + * @param [in] level @b SOL_CAN_RAW + * + * @param [in] optname @b CAN_RAW_TX_LOOPBACK + * + * @param [in] optval Pointer to integer value. + * + * @param [in] optlen Size of int: sizeof(int). + * + * Environments: non-RT (RT optional)@n + * @n + * Specific return values: + * - -EFAULT (It was not possible to access user space memory area at the + *specified address.) + * - -EINVAL (Invalid length optlen) + * - -EOPNOTSUPP (not supported, check RT-Socket-CAN kernel parameters). + */ +#define CAN_RAW_TX_LOOPBACK 0x3 + /** @} */ /*! @@ -933,6 +955,9 @@ * * The default value for a newly created socket is an infinite timeout. * + * @note The setting of the timeout value is not done atomically to avoid + * locks. Please set the value before receiving messages
Re: [Xenomai-core] [PATCH] RT-Socket-CAN, TX loopback and further improvements
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
@@ -894,6 +937,12 @@
/* We got access */
+#ifdef CONFIG_XENO_DRIVERS_RTCAN_TX_LOOPBACK
+/* Push message onto stack for loopback when TX done */
+if (sock-tx_loopback)
+rtcan_tx_push(dev, sock, frame);
+#endif /* CONFIG_XENO_DRIVERS_RTCAN_TX_LOOPBACK */
Hmm, I would prefer to define something like
if (rtcan_tx_loopback_enabled(sock))
rtcan_tx_push(dev, sock, frame);
with rtcan_tx_loopback_enabled resolving to 0 in the configured-out
case. Thus some #ifdefs could be moved from the code to central places
in header files.
OK, here I can avoid the #ifdef's ...
Index: ksrc/drivers/can/mscan/rtcan_mscan.c
===
--- ksrc/drivers/can/mscan/rtcan_mscan.c(revision 1834)
+++ ksrc/drivers/can/mscan/rtcan_mscan.c(working copy)
@@ -251,6 +251,21 @@
regs-cantier = 0;
/* Wake up a sender */
rtdm_sem_up(dev-tx_sem);
+
+#ifdef CONFIG_XENO_DRIVERS_RTCAN_TX_LOOPBACK
+if (dev-tx_socket) {
Same here. A macro like rtcan_tx_loopback_pending(dev) would avoid the
#ifdef.
...but not here. Or does the optimizer remove the if block?
AFAIK, all relevant gcc versions kill blocks like
if (0) {
...
}
from the binary. But one problem might appear: the block content must be
compilable in any case...
I'm going to checks this.
I think the timestamp should rather be passed to rtcan_tc_loopback and
set there. Or, if passing that value increases the code size needlessly,
rtcan_tx_loopback should be defined like
static inline void
rtcan_tx_loopback(struct rtcan_device *dev, nanosecs_abs_t timestamp)
{
set timestamp
__rtcan_tx_loopback(dev);
}
where __rtcan_tx_loopback is the uninlined code. That makes the driver
code leaner. Locking will hopefully change anyway, so nothing to do on
this part for now.
Or do it directly in rtcan_tx_loopback() and rtcan_recv(). Would it be
OK to read the time in these functions as well or should it be done, as
is, at the beginning of the ISR? I have already planned some similar
rewrite when Xenomai 2.3. is out, hopefully together with the new locking.
A few cycles offset of the timestamp doesn't matter here. We should just
avoid reading it more than once as this can be a costly operation on
some systems.
Hm, what does costly operation mean? Does it make sense then to read
the time only when really necessary e.g. not for pure TX done interrupts
and if nobody request them?
Wolfgang.
Jan
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] RT-Socket-CAN, TX loopback and further improvements
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
Hi Jan,
Jan Kiszka wrote:
Hi Wolfgang,
[...deletions...]
Last remark: For the sake of completeness, tx-loopback should also be
implemented in the virtual CAN driver.
The virtual CAN driver already works like TX loopback. It routes TX
messages to local foreign sockets (but without sending them to any bus).
There is a minor difference: When application A is attached to a socket
on virtual CAN device 1, B to device 2, and C to 1 again, a message sent
by A will only be received by B. TX loopback as you are introducing it
should make C receive it as well - in order to have a fully compatible
test environment.
Ah, I missed the case (rx_dev == tx_dev). This should work then:
/* Deliver to all other devices on the virtual bus */
for (i = 0; i devices; i++) {
rx_dev = rtcan_virt_devs[i];
if (rx_dev-state == CAN_STATE_ACTIVE) {
if (tx_dev != rx_dev) {
rx_frame-can_ifindex = rx_dev-ifindex;
rtcan_rcv(rx_dev, skb);
} else if (rtcan_tx_loopback_pending(tx_dev))
rtcan_tx_loopback(tx_dev);
}
}
Thanks.
Wolfgang.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Re: [Xenomai-help] RT-Socket-CAN update, please read
Jan Kiszka wrote: Hi Wolfgang, some more comments after looking at code and running a compiler: ... * ksrc/drivers/can/rtcan_raw.c, ksrc/drivers/can/sja1000/rtcan_sja1000.c, ksrc/drivers/can/mscan/rtcan_mscan.c: timestamps are now read and copied in rtcan_recv() and rtcan_tx_loopbcak(). ...thus multiple times in the same IRQ context if there are multiple packets pending. Do we gain enough from the new design that helps to compensate the drawback (considering slow rtdm_clock_read() I think you agree, that it's unlikely, that an RX interrupt is handled together with an TX done or an error interrupt. And we save reading the timestamp when there is just a TX done interrupt (without TX loopback, of course). It makes the driver dependent code simpler and cleaner. implementations)? Moreover, we may see a feature one day that the RTDM layer will provide you timestamps for an IRQ event (e.g. when the handler will be running at higher latency as a thread). Then we need to modify the interface to the driver anyhow. ... * ksrc/drivers/can/mscan/Kconfig, ksrc/drivers/can/sja1000/Kconfig, ksrc/drivers/can/Kconfig: add more help for kernel parameters. Suggestion: N x depends on XYZ = 1 x if XZY != n ... endif OK, no priority though. ... * ksrc/drivers/can/sja1000/rtcan_sja1000.c, ksrc/drivers/can/sja1000/rtcan_isa.c, ksrc/drivers/can/sja1000/rtcan_mem.c, ksrc/drivers/can/sja1000/rtcan_peak_pci.c, ksrc/drivers/can/sja1000/rtcan_peak_dng.c: Remove rtcan_dev_free() from rtcan_sja1000_unregister() to allow proper cleanup after the device has been unregistered. [2.4.33 build for x86] rtcan_peak_dng.c: In function `rtcan_peak_dng_exit_one': rtcan_peak_dng.c:315: warning: implicit declaration of function `rtcan_free_dev' Yes, I realized already this bug. [Not related to this change] In order to use the parport dongle also with recent PnP ports (e.g. in notebooks), you may want to have a look at the code I added to irqbench for this purpose: http://www.rts.uni-hannover.de/xenomai/lxr/source/ksrc/drivers/testing/irqbench.c?v=SVN-trunk#496 The background is that once you unload the parport module, the port will be powered off. Are there still laptops with parallel ports? Anyhow, I'm going to check that. ... * src/drivers/Makefile, ksrc/drivers/can/*, scripts/Modules.frag, src/utils/can/README: Replace rtcan with can in macro definitions CONFIG_XENO_DRIVERS_RTCAN_* and module names xeno_rtcan_* to comply to the common naming scheme. Hmm, wouldn't shortening some file names also make sense then? Well, we could remove rtcan_, but I have not time to do it now. Jan PS: 2.4 help patching and updating work nicely for me - except for choices which is obviously a 2.4 bug. I saw that the kernel then sometimes stuffs all information into the first item. Maybe scriptable for Xenomai... :- Yes, I observed the same behavior. Wolfgang. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Adeos support for 2.6.18 merged PowerPC architecture.
Benjamin Zores wrote: On Fri, 24 Nov 2006 11:13:03 +0100 Wolfgang Grandegger [EMAIL PROTECTED] wrote: Yes, the PowerPC tree is not yet supported. Yes but as i need it now i've decided to port it ;-) Or at least of a try. Good, :-) You might have realized my hack to get ride of radix-tree.h for the ppc tree. Actually not, have some patch ? For the ppc tree, I have added #ifdef CONFIG_PPC_MERGE #include linux/radix-tree.h #endif to include/powerpc/irq.h to get rid of the trouble with radix-tree.h. What defconfig do you use? Unfortunately I do not have a board by hand supported by the PowerPC tree. mpc834x_itx_defconfig I briefly reviewed your patch. At a first glance, it looks OK, but it is not yet complete and it does not compile. Quickly, I spotted the following problems: - NR_IRQS is not defined. This is a problem with the include weirdness due to radix-tree.h, IIRC. It is set to 512 for all PowerPC archs, puh, that's overkill (but not our problem for the time being). _ipipe_grab_irq(): special IRQ numbers have changed. Check for NO_IRQ_IGNORE in the attached patch. Also the new IRQ handling needs a more detailed review (check irq.c in the powerpc tree). - disarm_decr[] has disappeared. It was used to disable the programming of the decrementer in arch/ppc/kernel/time.c:timer_interrupt(). It needs an appropriate replacement in the powerpc tree. A quick, untested hack is in the attached patch. There might be more issues. We should also avoid code duplication of IPIPE files, but that's something I will fix later-on. Hope this helps you to get a bit further (kernel booted). Wolfgang. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Adeos support for 2.6.18 merged PowerPC architecture.
Forgot to attach the patch, sorry.
Wolfgang.
Wolfgang Grandegger wrote:
Benjamin Zores wrote:
On Fri, 24 Nov 2006 11:13:03 +0100
Wolfgang Grandegger [EMAIL PROTECTED] wrote:
Yes, the PowerPC tree is not yet supported.
Yes but as i need it now i've decided to port it ;-)
Or at least of a try.
Good, :-)
You might have realized my hack to get ride of radix-tree.h for the
ppc tree.
Actually not, have some patch ?
For the ppc tree, I have added
#ifdef CONFIG_PPC_MERGE
#include linux/radix-tree.h
#endif
to include/powerpc/irq.h to get rid of the trouble with radix-tree.h.
What defconfig do you use? Unfortunately I do not have a board by
hand supported by the PowerPC tree.
mpc834x_itx_defconfig
I briefly reviewed your patch. At a first glance, it looks OK, but it is
not yet complete and it does not compile. Quickly, I spotted the
following problems:
- NR_IRQS is not defined. This is a problem with the include weirdness
due to radix-tree.h, IIRC. It is set to 512 for all PowerPC archs, puh,
that's overkill (but not our problem for the time being).
_ipipe_grab_irq(): special IRQ numbers have changed. Check for
NO_IRQ_IGNORE in the attached patch. Also the new IRQ handling needs a
more detailed review (check irq.c in the powerpc tree).
- disarm_decr[] has disappeared. It was used to disable the programming
of the decrementer in arch/ppc/kernel/time.c:timer_interrupt(). It needs
an appropriate replacement in the powerpc tree. A quick, untested hack
is in the attached patch.
There might be more issues.
We should also avoid code duplication of IPIPE files, but that's
something I will fix later-on.
Hope this helps you to get a bit further (kernel booted).
Wolfgang.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Index: linux-2.6.18/arch/powerpc/kernel/time.c
===
--- linux-2.6.18.orig/arch/powerpc/kernel/time.c
+++ linux-2.6.18/arch/powerpc/kernel/time.c
@@ -699,9 +699,15 @@ void timer_interrupt(struct pt_regs * re
}
write_sequnlock(xtime_lock);
}
-
+#ifdef CONFIG_IPIPE
+ if (__ipipe_decr_ticks == tb_ticks_per_jiffy) {
+ next_dec = tb_ticks_per_jiffy - ticks;
+ set_dec(next_dec);
+ }
+#else /* !CONFIG_IPIPE */
next_dec = tb_ticks_per_jiffy - ticks;
set_dec(next_dec);
+#endif /* CONFIG_IPIPE */
#ifdef CONFIG_PPC_ISERIES
if (hvlpevent_is_pending())
Index: linux-2.6.18/arch/powerpc/kernel/ipipe-core.c
===
--- linux-2.6.18.orig/arch/powerpc/kernel/ipipe-core.c
+++ linux-2.6.18/arch/powerpc/kernel/ipipe-core.c
@@ -224,7 +224,6 @@ static void __ipipe_set_decr(void)
ipipe_load_cpuid();
- disarm_decr[cpuid] = (__ipipe_decr_ticks != tb_ticks_per_jiffy);
#ifdef CONFIG_40x
/* Enable and set auto-reload. */
mtspr(SPRN_TCR, mfspr(SPRN_TCR) | TCR_ARE);
Index: linux-2.6.18/arch/powerpc/kernel/ipipe-root.c
===
--- linux-2.6.18.orig/arch/powerpc/kernel/ipipe-root.c
+++ linux-2.6.18/arch/powerpc/kernel/ipipe-root.c
@@ -314,7 +314,9 @@ int __ipipe_grab_irq(struct pt_regs *reg
ipipe_declare_cpuid;
int irq;
- if ((irq = ppc_md.get_irq(regs)) = 0) {
+ irq = ppc_md.get_irq(regs);
+
+ if (irq != NO_IRQ irq != NO_IRQ_IGNORE) {
#ifdef CONFIG_IPIPE_TRACE_IRQSOFF
ipipe_trace_begin(irq);
#endif /* CONFIG_IPIPE_TRACE_IRQSOFF */
@@ -323,7 +325,7 @@ int __ipipe_grab_irq(struct pt_regs *reg
ipipe_trace_end(irq);
#endif /* CONFIG_IPIPE_TRACE_IRQSOFF */
}
- else if (irq != -2)
+ else if (irq != NO_IRQ_IGNORE)
ppc_spurious_interrupts++;
ipipe_load_cpuid();
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Adeos support for 2.6.18 merged PowerPC architecture.
Benjamin Zores wrote: On Mon, 27 Nov 2006 12:21:25 +0100 Wolfgang Grandegger [EMAIL PROTECTED] wrote: Well, I hack a bit my patch to make it compile and the kernel already booted. Though it hangs when loading the SATA driver. I have no idea why atm. Problems with IRQs? Probably, as when unplugging the SATA drive, the boot goes further but then hang at USB detection (both are handlign IRQs a lot i guess). Would be interesting if someone could test on other board than just mine. As I pointed out in my previous mail, the IRQ handling is not yet correct for powerpc. Try to correct his first. Wolfgang. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Adeos support for 2.6.18 merged PowerPC architecture.
Jan Kiszka wrote: Benjamin Zores wrote: On Mon, 27 Nov 2006 13:11:23 +0100 Wolfgang Grandegger [EMAIL PROTECTED] wrote: Benjamin Zores wrote: On Mon, 27 Nov 2006 12:21:25 +0100 Wolfgang Grandegger [EMAIL PROTECTED] wrote: Well, I hack a bit my patch to make it compile and the kernel already booted. Though it hangs when loading the SATA driver. I have no idea why atm. Problems with IRQs? Probably, as when unplugging the SATA drive, the boot goes further but then hang at USB detection (both are handlign IRQs a lot i guess). Would be interesting if someone could test on other board than just mine. As I pointed out in my previous mail, the IRQ handling is not yet correct for powerpc. Try to correct his first. The 2.6.19 having been released out, and working much better on my card than the vanilla 2.6.18 used to be, I'm now more kind to adapt my patch to this latest kernel. However the IRQ handling API seem to have changed a lot and i was wondering if some work on porting Adeos (x86/ppc, not yet powerpc of course) patches already have been started by someone here ? I don't see that PPC is converted to genirq, that new API. And I'm not sure (while not being a PPC expert) if it ever will be, specifically as PowerPC is already on genirq and should obsolete PPC one day, right? No, or at least partially wrong. I have to check what the new, fully implemented genirq does. But I realized, that the common IRQ structure is used now (resulting in some name changes, w.g. -handler -chip). Likely, PPC and PowerPC already use the new genirq. Anyway, there is an unreleased work-in-progress patch for x86 over -rc6 by Philippe. I recently had the chance to test it and hack a bit on the SMP IO-APIC part. It seems to work fine under UP, but SMP had some issues that are identified, but still need to be addressed - thanks to genirq, now in a widely arch-independent way. Philippe, I know you are very busy, but shouldn't we make a pre-release available already, also to discuss further how to deal best with genirq on other platforms beyond x86? Jan ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Adeos support for 2.6.18 merged PowerPC architecture.
Benjamin Zores wrote: On Mon, 27 Nov 2006 13:11:23 +0100 Wolfgang Grandegger [EMAIL PROTECTED] wrote: Benjamin Zores wrote: On Mon, 27 Nov 2006 12:21:25 +0100 Wolfgang Grandegger [EMAIL PROTECTED] wrote: Well, I hack a bit my patch to make it compile and the kernel already booted. Though it hangs when loading the SATA driver. I have no idea why atm. Problems with IRQs? Probably, as when unplugging the SATA drive, the boot goes further but then hang at USB detection (both are handlign IRQs a lot i guess). Would be interesting if someone could test on other board than just mine. As I pointed out in my previous mail, the IRQ handling is not yet correct for powerpc. Try to correct his first. The 2.6.19 having been released out, and working much better on my card than the vanilla 2.6.18 used to be, I'm now more kind to adapt my patch to this latest kernel. I know this problem very well. The PowerPC Linux kernel is currently a fast moving target and 2.6.19 breaks the Adeos-IPIPE ppc patch again, grrr. However the IRQ handling API seem to have changed a lot and i was wondering if some work on porting Adeos (x86/ppc, not yet powerpc of course) patches already have been started by someone here ? (i.e. something i can work from to adapt my new patch) I will have a look when time permits. Hopefully end of this week. If I'm lucky, I may get the PowerPC tree up and running on my Lite5200. There are already some promising patches around. Wolfgang. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [ANNOUNCE] Xenomai Example Repository
Jan Kiszka wrote: Wolfgang Grandegger wrote: Jan Kiszka wrote: Hi, the new Xenomai example repository has been created. I don't want to repeat here what is explained already on the related wiki page, please have a look at http://www.xenomai.org/index.php/Examples Instead, let me sketch what could be done next: o Port existing examples, snippets, demos from ksrc/skins/* over, make them compilable and runnable if required. o Identify what kind of examples are lacking. You, the user, is needed here. What do *you* think is missing, what would be helpful to show? o Check what is needed to compile kernel-based examples over PPC 2.4. Philippe indicated that some switches are likely missing (x86 is fine already, other archs are 2.6-only). Some time ago I sent a patch for RTnet using the kernel CFLAGS capturing trick to get proper switches for 2.4: http://sourceforge.net/mailarchive/forum.php?thread_id=9493711forum_id=24610 We could do the same trick here. Yeah, I had a look at this before. The point is that I would prefer to keep things _simple_ and self-contained. This capturing requires some helper Makefile and complex call nestings that likely only people with advanced make and shell skills can understand and adopt to their projects. But maybe things are that complicated already, and this is just different complexity. How do you compile simple out-of-tree modules against 2.4 PPC kernels? Are there any standard flags? Or is it different for each board or each compiler version or whatever? I just cut and paste the flags from a kernel module make. For PPC, there are plenty of flags, not board but some are processor depended, but I'm unable to tell which one are really required. For this reason I like the module capturing trick. Wolfgang. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-help] Re: [Xenomai-core] [ANNOUNCE] Xenomai Example Repository
Philippe Gerum wrote: On Fri, 2006-12-01 at 18:22 +0100, Jan Kiszka wrote: Wolfgang Grandegger wrote: Jan Kiszka wrote: Hi, the new Xenomai example repository has been created. I don't want to repeat here what is explained already on the related wiki page, please have a look at http://www.xenomai.org/index.php/Examples Instead, let me sketch what could be done next: o Port existing examples, snippets, demos from ksrc/skins/* over, make them compilable and runnable if required. o Identify what kind of examples are lacking. You, the user, is needed here. What do *you* think is missing, what would be helpful to show? o Check what is needed to compile kernel-based examples over PPC 2.4. Philippe indicated that some switches are likely missing (x86 is fine already, other archs are 2.6-only). Some time ago I sent a patch for RTnet using the kernel CFLAGS capturing trick to get proper switches for 2.4: http://sourceforge.net/mailarchive/forum.php?thread_id=9493711forum_id=24610 We could do the same trick here. Yeah, I had a look at this before. The point is that I would prefer to keep things _simple_ and self-contained. This capturing requires some helper Makefile and complex call nestings that likely only people with advanced make and shell skills can understand and adopt to their projects. I tend to agree on the keep it simple mantra, but still, there are at least two other aspects which are quite important too: - Nobody should expect to be able to develop a complete project only relying on paste-and-copy of example code. Since we are specifically talking about Makefile rules, we could not provide any set that would match everyone's project anyway, with respect to software and hardware requirements. Therefore, at some point, people really need to know what they are doing, which means that they should also know how to properly build out-of-tree modules with _their_ own 2.4 setup (well, if any proper solution exists, that is). And basically, I do hope that nobody starts implementing kernel modules without having - at least - a vague idea, about how to compile them for its platform in the first place... - Given that there is life beyond x86, we need to make sure that all Xenomai ports are considered equal, at least with respect to generic issues. Whilst it's ok to provide a x86-only 2.4 Makefile for compiling a x86-centric example, it's not for anything which could demonstrate a feature on any platform. This said, I agree that adding a fake module directory to capture the flags set by the main kernel Makefile is one step beyond ugliness; the other approach being to only provide a 2.6 Makefile frag. As 2007 approaches, I think that anyone still involved with projects relying on 2.4 kernels do know how to build 2.4 modules for the targeted platform. I think the example modules should compile on any platform and the kernel CFLAGS capturing trick is the most straight-forward way to do it for 2.4. It simplifies our life, avoids fiddling with various arch dependent flags in the Makefile, which will be even more ugly, and it serves as an example on how to get proper flags. Therefore I tend to add an appropriate script to the scripts subdirectory. But maybe things are that complicated already, and this is just different complexity. How do you compile simple out-of-tree modules against 2.4 PPC kernels? Are there any standard flags? Or is it different for each board or each compiler version or whatever? Jan ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Adeos support for 2.6.18 merged PowerPC architecture.
Philippe Gerum wrote: On Fri, 2006-12-01 at 23:46 +0100, Philippe Gerum wrote: On Thu, 2006-11-30 at 14:19 +0100, Jan Kiszka wrote: Anyway, there is an unreleased work-in-progress patch for x86 over -rc6 by Philippe. I recently had the chance to test it and hack a bit on the SMP IO-APIC part. It seems to work fine under UP, but SMP had some issues that are identified, but still need to be addressed - thanks to genirq, now in a widely arch-independent way. Philippe, I know you are very busy, but shouldn't we make a pre-release available already, also to discuss further how to deal best with genirq on other platforms beyond x86? Actually, the draft patch I sent you did not boot on my SMP box today, so qemu seems to have been a bit too friendly. Knowing that, issuing a half-baked patch would have made no sense, so I finally refrained from doing that. Since I'm now basically in love with the genirq layer (at least for x86) compared to the utter mess that we had to endure previously, I've decided to tackle the issue completely, and rewrite the I-pipe interrupt flow in order to leverage it. Will post something asap. Ok, here we are. I've just merged 2.6.19-ipipe-1.6-00. It has been tested on a low-end classic Pentium 90Mhz, a dusty two-way Celeron 750Mhz, and on a terrible Celeron 1GHz oldish laptop. Looks ok so far, and even passed the horrid dohell test on the SMP box, just smiling. However, I don't have the required hw at hand to check if our friend the MSI support is not killing us once more. This said, the MSI support in 2.6.19 also conforms to the genirq specs, so there's hope. The patch is available from the Adeos download area, and I've also committed it to the SVN trunk/. Feedback welcome, PS: I have the corresponding quilt-managed patches available upon request, to the people who want to use this work as a reference for porting to other archs. You mean that you have separate patches for the common and arch dependent part. That would be nice. I'm interested! As a consequence we could provide separated patches in general and prepare-kernel.sh applies them in sequence. Just an idea for the future. Wolfgang. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Adeos support for 2.6.18 merged PowerPC architecture.
Philippe Gerum wrote: On Sat, 2006-12-02 at 10:36 +0100, Wolfgang Grandegger wrote: Philippe Gerum wrote: On Fri, 2006-12-01 at 23:46 +0100, Philippe Gerum wrote: On Thu, 2006-11-30 at 14:19 +0100, Jan Kiszka wrote: Anyway, there is an unreleased work-in-progress patch for x86 over -rc6 by Philippe. I recently had the chance to test it and hack a bit on the SMP IO-APIC part. It seems to work fine under UP, but SMP had some issues that are identified, but still need to be addressed - thanks to genirq, now in a widely arch-independent way. Philippe, I know you are very busy, but shouldn't we make a pre-release available already, also to discuss further how to deal best with genirq on other platforms beyond x86? Actually, the draft patch I sent you did not boot on my SMP box today, so qemu seems to have been a bit too friendly. Knowing that, issuing a half-baked patch would have made no sense, so I finally refrained from doing that. Since I'm now basically in love with the genirq layer (at least for x86) compared to the utter mess that we had to endure previously, I've decided to tackle the issue completely, and rewrite the I-pipe interrupt flow in order to leverage it. Will post something asap. Ok, here we are. I've just merged 2.6.19-ipipe-1.6-00. It has been tested on a low-end classic Pentium 90Mhz, a dusty two-way Celeron 750Mhz, and on a terrible Celeron 1GHz oldish laptop. Looks ok so far, and even passed the horrid dohell test on the SMP box, just smiling. However, I don't have the required hw at hand to check if our friend the MSI support is not killing us once more. This said, the MSI support in 2.6.19 also conforms to the genirq specs, so there's hope. The patch is available from the Adeos download area, and I've also committed it to the SVN trunk/. Feedback welcome, PS: I have the corresponding quilt-managed patches available upon request, to the people who want to use this work as a reference for porting to other archs. You mean that you have separate patches for the common and arch dependent part. Mostly, yes. The patches are split by function, but this usually correlates with the noarch / arch-specific break down view too. That would be nice. I'm interested! http://download.gna.org/adeos/patches/v2.6/i386/split/ As a consequence we could provide separated patches in general and prepare-kernel.sh applies them in sequence. Just an idea for the future. Problem is that we would have to store a set of patches for each Adeos version/arch combo, instead of a single one. What advantage do you see in breaking the Adeos patches down for prepare-kernel.sh? Maintenance issues for the noarch part, e.g., if you fix a bug in the common part or add new features it's available for all arch. But I see your point. It's a bit more complicated and there are also patch version numbers. Wolfgang. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [ANNOUNCE] Xenomai Example Repository
Hi Jan,
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
Jan Kiszka wrote:
Hi,
the new Xenomai example repository has been created. I don't want to
repeat here what is explained already on the related wiki page, please
have a look at
http://www.xenomai.org/index.php/Examples
Instead, let me sketch what could be done next:
o Port existing examples, snippets, demos from ksrc/skins/* over, make
them compilable and runnable if required.
o Identify what kind of examples are lacking. You, the user, is needed
here. What do *you* think is missing, what would be helpful to show?
o Check what is needed to compile kernel-based examples over PPC 2.4.
Philippe indicated that some switches are likely missing (x86 is fine
already, other archs are 2.6-only).
Some time ago I sent a patch for RTnet using the kernel CFLAGS
capturing trick to get proper switches for 2.4:
http://sourceforge.net/mailarchive/forum.php?thread_id=9493711forum_id=24610
We could do the same trick here.
Yeah, I had a look at this before. The point is that I would prefer to
keep things _simple_ and self-contained. This capturing requires some
helper Makefile and complex call nestings that likely only people with
advanced make and shell skills can understand and adopt to their projects.
But maybe things are that complicated already, and this is just
different complexity. How do you compile simple out-of-tree modules
against 2.4 PPC kernels? Are there any standard flags? Or is it
different for each board or each compiler version or whatever?
I just cut and paste the flags from a kernel module make. For PPC, there
are plenty of flags, not board but some are processor depended, but I'm
unable to tell which one are really required. For this reason I like the
module capturing trick.
What about this patch? I /seems/ to work (yeah, only tested on x86...), merging
the
whole capturing stuff into the same Makefile. Please give it hell on PPC.
The attached Makefile works. I had to fix two problems. First, cross
compilation was not supported. I now take the CC from xeno-config --cc
for user space applications. I think xeno-config is intended only for
making user space applications and therefore CC should be specified on
the command line for kernel modules:
$ make KSRC=/devel/linuxppc_2_4_devel ARCH=ppc CC=ppc-linux-gcc
ppc-linux-gcc -D__KERNEL__ -I/devel/linuxppc_2_4_devel/include -Wall
-Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common
-fomit-frame-pointer -I/devel/linuxppc_2_4_devel/arch/ppc -fsigned-char
-msoft-float -pipe -ffixed-r2 -Wno-uninitialized -mmultiple -mstring -g
-ggdb -DMODULE
-I/devel/linuxppc_2_4_devel-2006_11_21_1134/include/xenomai
-I/devel/linuxppc_2_4_devel-2006_11_21_1134/include/xenomai/compat
-I/devel/linuxppc_2_4_devel-2006_11_21_1134/include/xenomai/posix-c
-o heartbeat-x86.o heartbeat-x86.c
Furthermore I removed -I$(KSRC)/include, it is already included in the
captured CFLAGS.
Wolfgang.
Index: rtdm/driver-api/Makefile
===
--- rtdm/driver-api/Makefile(Revision 1916)
+++ rtdm/driver-api/Makefile(Arbeitskopie)
@@ -47,23 +47,23 @@ ifneq ($(MODULES),)
OBJS := ${patsubst %, %.o, $(MODULES)}
CLEANMOD := ${patsubst %, .%*, $(MODULES)}
+PWD := $(shell if [ $$PWD != ]; then echo $$PWD; else pwd; fi)
-# Kernel 2.6
+### Kernel 2.6
ifeq ($(findstring 2.6,$(KSRC)),2.6)
obj-m:= $(OBJS)
EXTRA_CFLAGS := -I$(KSRC)/include/xenomai -I$(KSRC)/include/xenomai/posix
$(ADD_CFLAGS)
-PWD := $(shell pwd)
all::
$(MAKE) -C $(KSRC) SUBDIRS=$(PWD) modules
-# Kernel 2.4
+### Kernel 2.4
else
+ARCH?= $(shell uname -i)
INCLUDE := -I$(KSRC)/include -I$(KSRC)/include/xenomai
-I$(KSRC)/include/xenomai/compat -I$(KSRC)/include/xenomai/posix
-CFLAGS += -O2 -Wall -Wstrict-prototypes -Wno-trigraphs -DMODULE -D__KERNEL__
-DLINUX \
- -fno-strict-aliasing -fno-common $(INCLUDE) $(ADD_CFLAGS)
+CFLAGS += $(shell $(MAKE) -s -C $(KSRC) CC=$(CC) ARCH=$(ARCH) SUBDIRS=$(PWD)
modules) $(INCLUDE) $(ADD_CFLAGS)
all:: $(OBJS)
@@ -74,3 +74,7 @@ clean::
$(RM) -R .tmp*
endif
+
+## Target for capturing 2.4 module CFLAGS
+modules:
+ @echo $(CFLAGS)
Jan
## CONFIGURATION ##
### List of applications to be build
APPLICATIONS =
### Note: to override the search path for the xeno-config script, use make
XENO=...
### List of modules to be build
MODULES = heartbeat-x86
### Default to sources of currently running kernel
KSRC ?= /lib/modules/$(shell uname -r)/build
### Note: to override the kernel source path, use make KSRC=...
## USER SPACE BUILD (no change required normally
Re: [Xenomai-core] [PATCH] Adeos support for 2.6.18 merged PowerPC architecture.
Benjamin Zores wrote: On Mon, 27 Nov 2006 13:11:23 +0100 Wolfgang Grandegger [EMAIL PROTECTED] wrote: Benjamin Zores wrote: On Mon, 27 Nov 2006 12:21:25 +0100 Wolfgang Grandegger [EMAIL PROTECTED] wrote: Well, I hack a bit my patch to make it compile and the kernel already booted. Though it hangs when loading the SATA driver. I have no idea why atm. Problems with IRQs? Probably, as when unplugging the SATA drive, the boot goes further but then hang at USB detection (both are handlign IRQs a lot i guess). Would be interesting if someone could test on other board than just mine. As I pointed out in my previous mail, the IRQ handling is not yet correct for powerpc. Try to correct his first. The 2.6.19 having been released out, and working much better on my card than the vanilla 2.6.18 used to be, I'm now more kind to adapt my patch to this latest kernel. OK. However the IRQ handling API seem to have changed a lot and i was wondering if some work on porting Adeos (x86/ppc, not yet powerpc of course) patches already have been started by someone here ? I have now a preliminary patch for adeos-ipipe-2.6.19-ppc-1.5-00. The porting was rather straight-forward, as the ppc tree does not use the new genirq interface, in contrast to the powerpc tree (that's what you have realized as well). (i.e. something i can work from to adapt my new patch) Therefore the port of the powerpc tree should be based on Philippe's new adeos-ipipe-2.6.19-i386-1.6-00. Unfortunately, I still do not have a board by hand supported by the powerpc tree. Wolfgang. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Adeos support for 2.6.18 merged PowerPC architecture.
Benjamin Zores wrote: On Tue, 05 Dec 2006 11:17:07 +0100 Wolfgang Grandegger [EMAIL PROTECTED] wrote: I have now a preliminary patch for adeos-ipipe-2.6.19-ppc-1.5-00. The porting was rather straight-forward, as the ppc tree does not use the new genirq interface, in contrast to the powerpc tree (that's what you have realized as well). Well, i guess the old ppc arch is bound to die sooner or later. New developments should always be done against powerpc arch imho. Well, the powerpc tree is still highly experimental and only a few embedded boards are already supported. I guess it will take a long time before the ppc tree finally gets buried, especially because porting is not really trivial (due to OF, IRQ layer, etc.), Therefore the port of the powerpc tree should be based on Philippe's new adeos-ipipe-2.6.19-i386-1.6-00. Unfortunately, I still do not have a board by hand supported by the powerpc tree. I haven't had much much time investigating the problem till now. But from what i've seen from Philippe's splitted patches, many of them that were supposed to be generic (i.e. don't have i386 in their name) still have references to x86 changes. Is it a normal behavior ? Unfortunately, generic applies only to the Linux part. I realized, that the new IPIPE support for the genirqs requires even more arch-specific modifications than the old interface :-( on PowerPC. (about dev board, no one's developing on lite5200 or sth like that ?) Have you ever worked with that board under 2.6? It is not even well supported by the old ppc tree and you need patches, which are available somewhere but still require extra tweaking. I have such a board on my table and if I'm lucky, I will get U-Boot with OF support up and booting Linux PowerPC 2.6.19 ... but I need plenty of luck. Wolfgang. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
