Re: [Xenomai-core] I-pipe patch for ARM S3C24xx (v4)
Sebastian Smolorz wrote: Hi all, now that the teething problems of my I-pipe port to the S3C24xx are cured (hopefully ...) I'm going to iterate it to v4. We've established a project homepage for that port http://opensource.emlix.com/ipipe-s3c24xx/ What happens with __ipipe_mach_irq_mux_p if irq is smaller than IRQ_CAM ? -- Gilles Chanteperdrix ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] I-pipe patch for ARM S3C24xx (v4)
Am Freitag, 10. November 2006 11:14 schrieb Gilles Chanteperdrix: Sebastian Smolorz wrote: Hi all, now that the teething problems of my I-pipe port to the S3C24xx are cured (hopefully ...) I'm going to iterate it to v4. We've established a project homepage for that port http://opensource.emlix.com/ipipe-s3c24xx/ What happens with __ipipe_mach_irq_mux_p if irq is smaller than IRQ_CAM ? OK, this is not correct. I will fix it to #define __ipipe_irqbit(irq) (1 ((irq) - S3C2410_CPUIRQ_OFFSET)) as you suggested originally. Thanks, Sebastian ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [PATCH] Missing include when compiling an ipiped Linux kernel with CONFIG_PREEMPT for ARM
Hi, here comes a fix for I-pipe for ARM. Without it the kernel refuses to compile when configured with CONFIG_PREEMPT. Sebastian --- linux-2.6.15-ipipe.orig/include/asm-arm/ipipe.h 2006-11-08 16:44:02.0 +0100 +++ linux-2.6.15-ipipe.work/include/asm-arm/ipipe.h 2006-11-10 12:12:44.0 +0100 @@ -34,6 +34,7 @@ #include asm/irq.h #include asm/bitops.h #include asm/mach/irq.h +#include asm/percpu.h #define IPIPE_ARCH_STRING 1.5-02 #define IPIPE_MAJOR_NUMBER 1 @@ -51,7 +52,7 @@ #endif /* CONFIG_SMP */ /* Note that we disable the interrupts around context_switch, - * or we'll get into severe problems when scheduling Xenomaï + * or we'll get into severe problems when scheduling Xenomai's * user space real time threads. * This can however cause high latencies, see for example: * http://www.ussg.iu.edu/hypermail/linux/kernel/0405.2/1388.html ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[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] Xenomai v2.2.5
On Wed, 2006-11-08 at 16:53 +0800, Li Yi (Adam) wrote: Another typo in xenomai-2.2.5/ksrc/drivers/testing/timerbench.c: 412: printk(%s: bad ioctl code (0x%x)\n, _ _FUNCTION_, request); should be: printk(%s: bad ioctl code (0x%x)\n, _ _FUNCTION_ _, request); Yeah, rainy day indeed... Both fixed in the download area too. Thanks. -Yi On 11/7/06, Philippe Gerum [EMAIL PROTECTED] wrote: On Tue, 2006-11-07 at 14:32 +0800, Li Yi (Adam) wrote: Hi Philippe, Not sure you have noticed this typo or not: xenomai-2.2.5/ksrc/skins/posix/syscall.c 2674: nt __pse51_call_not_available(struct task_struct *curr, struct pt_regs *regs) should be: int __pse51_call_not_available(struct task_struct *curr, struct pt_regs *regs) Fixed, thanks. Regards, -Yi On 11/6/06, Philippe Gerum [EMAIL PROTECTED] wrote: Here is the fifth maintenance release for the v2.2.x branch. Short log follows: [nucleus] * Fix period validity check when setting up the timer for periodic timing mode. [hal] * ppc: Define special wrappers to get/put_user macros which bypass the might_sleep() checks. Upgrade Adeos support. * x86: Upgrade Adeos support. * arm: Upgrade Adeos support. [native] * Fix rt_queue_send() upon null broadcast (wrong reference count). [posix] * Make sure to read interrupt-related macros from the core headers when including posix/pthread.h from user-space. See the ChangeLog for details. http://download.gna.org/xenomai/stable/xenomai-2.2.5.tar.bz2 -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core -- Philippe. -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Re: [Adeos-main] ipip tracer porting for blackfin
On Fri, 2006-11-10 at 21:54 +0800, Li Yi (Adam) wrote: Hi Jan and Philippe, I have tested the adeos-ipipe-bf53x-CVS-20061008-1.5-00.patch in Xenomai-2.2.5 with latest Blackfin uclinux toolchain 06r2 release: http://blackfin.uclinux.org/frs/download.php/1136/blackfin-toolchain-06r2-5.i386.rpm. Since the toolchain changed a little for the mcount call, the ipipe-tracer patch need to be updated a little. Also I add trace for IRQ entry and exit as Jan suggested. Here is the details of the patch (with my explanation) diff -Nur linux-2.6.x-ipipe-orig/arch/blackfin/kernel/ipipe-mcount.S linux-2.6.x-ipipe/arch/blackfin/kernel/ipipe-mcount.S --- linux-2.6.x-ipipe-orig/arch/blackfin/kernel/ipipe-mcount.S 2006-11-10 21:04:21.0 +0800 +++ linux-2.6.x-ipipe/arch/blackfin/kernel/ipipe-mcount.S 2006-11-10 16:41:11.0 +0800 @@ -12,7 +12,7 @@ .align 4 /* just in case */ -ENTRY(_mcount) +ENTRY(__mcount) [--sp] = ( r7:0, p5:0 ); [--sp] = ASTAT; p1.L = _ipipe_trace_enable; diff -Nur linux-2.6.x-ipipe-orig/arch/blackfin/kernel/ipipe-root.c linux-2.6.x-ipipe/arch/blackfin/kernel/ipipe-root.c --- linux-2.6.x-ipipe-orig/arch/blackfin/kernel/ipipe- root.c 2006-11-10 21:04:21.0 +0800 +++ linux-2.6.x-ipipe/arch/blackfin/kernel/ipipe-root.c 2006-11-10 16:41:59.0 +0800 @@ -281,6 +281,6 @@ EXPORT_SYMBOL(show_stack); #ifdef CONFIG_IPIPE_TRACE_MCOUNT -void notrace mcount(void); -EXPORT_SYMBOL(mcount); +void notrace _mcount(void); +EXPORT_SYMBOL(_mcount); #endif /* CONFIG_IPIPE_TRACE_MCOUNT */ Yi's note: The gcc will add Call _ _mcount to each function entry when there is -pg option Ok. diff -Nur linux-2.6.x-ipipe-orig/arch/blackfin/mach-common/interrupt.S linux-2.6.x-ipipe/arch/blackfin/mach-common/interrupt.S --- linux-2.6.x-ipipe-orig/arch/blackfin/mach-common/interrupt.S 2006-11-10 21:04: 21.0 +0800 +++ linux-2.6.x-ipipe/arch/blackfin/mach-common/interrupt.S 2006-11-10 16:43:55.0 +0800 @@ -304,7 +304,10 @@ p0.l = _irq_flags; p0.h = _irq_flags; r0 = [p0]; - sti r0 + sti r0; + /* Reenable interrupts */ + [--sp] = reti; + r0 = [sp++]; rts; #endif /* CONFIG_IPIPE */ Yi's Note: I used the ipipe-trace to trace the latency test case: latency -t2 -p200 -f. And found that __ipipe_call_irqtail() will disable global interrupts, putting the Blackfin to a state like: IMASK: 0x, ILAT: 0x0040, IPEND: 0xc010 - that is, Core Timer irq latched, but since IPEND[4] is set, the irq handler cannot be invoked - thus longer latency. Good catch, I forgot the fact that triggering an IRQ to run the scheduling tail would raise the global disable bit. Applied, thanks. [...] -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Re: [Adeos-main] ipip tracer porting for blackfin
Li Yi (Adam) wrote:
Hi Jan and Philippe,
...
Also attached the new ipiper-tracer log.
Damn, no fitting reference trace at hand, but something seems to be
fishy. See comments/questions below.
root:~ ./latency -t2 -p200 -f
root:~ cat /proc/ipipe/trace/frozen
I-pipe frozen back-tracing service on 2.6.16.27-ADI-2006R2/ipipe-1.5-00
Freeze: 144879102832 cycles, Trace Points: 200 (+50)
+- Hard IRQs ('|': locked)
|+ unused
||+--- unused
|||+-- Xenomai
+- Linux ('*': domain stalled, '+': current, '#': current+stalled)
|+-- Delay flag ('+': 1 us, '!': 10
us)
||+- NMI noise ('N')
|||
TypeUser Val. TimeDelay Function (Parent)
...
:+func -98+ 1.550 _kthread_should_stop+0x10
(_gatekeeper_thread+0xec)
:| +begin 0x8001 -97+ 2.898 _gatekeeper_thread+0x100
(__start+0xf000)
:| *+func -94+ 1.432 _xnpod_resume_thread+0xa
(_gatekeeper_thread+0x186)
:| *+[ 51] -?-0 -92+ 5.450 _xnpod_resume_thread+0x4a
(__start+0xf000)
Here we go: harden the xeno thread related to pid 51 (likely some now
gone part of latency).
http://www.rts.uni-hannover.de/xenomai/lxr/source/ksrc/nucleus/pod.c#L1555
:| *+func -87+ 1.100 _xnpod_schedule_runnable+0xc
(_gatekeeper_thread+0x1be)
:| *+[0] swapper -1 -86+ 2.788 _xnpod_schedule_runnable+0x28
(__start+0xf000)
This correlates to
http://www.rts.uni-hannover.de/xenomai/lxr/source/ksrc/nucleus/pod.c#L2529
xnpod_schedule_runnable returns without actually switching (off-topic:
seems to be the only use-case for this function right now...).
:| *+func -83+ 2.852 _xnpod_schedule+0xa
(_gatekeeper_thread+0x1ce)
:| *+func -80+ 2.970 _ipipe_trigger_irq+0x12
(_xnpod_schedule+0x2e6)
:| *+func -77+ 2.120 ___ipipe_handle_irq+0x1e
(_ipipe_trigger_irq+0x86)
:| *+func -75+ 2.058 ___ipipe_dispatch_wired+0x14
(___ipipe_handle_irq+0x190)
:| *+func -73+ 1.722 ___ipipe_restore_pipeline_head+0xa
(_gatekeeper_thread+0x138)
:| +func -71+ 2.130 ___ipipe_walk_pipeline+0x18
(___ipipe_restore_pipeline_head+0xd0)
:| + func -69+ 2.410 _ipipe_suspend_domain+0xa
(___ipipe_walk_pipeline+0xac)
:| + func -67+ 5.048 ___ipipe_sync_stage+0xe
(_ipipe_suspend_domain+0x4e)
:| # func -62+ 2.452 _xnpod_schedule_handler+0xe
(___ipipe_sync_stage+0x186)
:| # func -59+ 2.130 _xnpod_schedule+0xa
(_xnpod_schedule_handler+0x5c)
:| # [0] swapper -1 -57+ 7.180 _xnpod_schedule+0x104
(__start+0xf000)
This must be
http://www.rts.uni-hannover.de/xenomai/lxr/source/ksrc/nucleus/pod.c#L2337
saying root thread is about the be scheduled away. But then I'm
missing code here that one would normally see on x86:
http://www.rts.uni-hannover.de/xenomai/lxr/source/ksrc/nucleus/pod.c#L2442
Likely inlined on bfin, but this *must* make some noise:
http://www.rts.uni-hannover.de/xenomai/lxr/source/ksrc/nucleus/pod.c#L2453
Instead we enter the pending timer interrupt. This currently makes no
sense to me, rather make me think that something is skewed. Maybe only
the tracer, maybe more...
:| # end 0x8000 -50+ 2.278 ___sched_text_start+0x5ca
(__start+0xf000)
:| # func -480.922 ___ipipe_grab_irq+0x22
(__common_int_entry+0x72)
:| # begin 0x0006 -47+ 1.820 ___ipipe_grab_irq+0x34
(__start+0xf000)
:| # func -45+ 1.530 ___ipipe_handle_irq+0x1e
(___ipipe_grab_irq+0x3c)
:| # func -43+ 1.168 _rthal_timer_ack+0x8
(___ipipe_handle_irq+0x178)
:| # func -42+ 1.102 ___ipipe_dispatch_wired+0x14
(___ipipe_handle_irq+0x190)
:| # end 0x0006 -41+ 2.010 ___ipipe_grab_irq+0x42
(__start+0xf000)
: # func -39+ 1.090 _ipipe_unstall_pipeline_head+0x8
(_xnshadow_harden+0xce)
:| # begin 0x8001 -38+ 2.308 _ipipe_unstall_pipeline_head+0x18
(__start+0xf000)
That's another weirdness, but now very likely of the tracer: both
tracepoints should contain the same parent entry, but the second one is
just nonsense. And there are such kind of parents all over the place -
hmm, actually any explicit trace point shows this problem. Is there no
way on bfin to get the caller from everywhere in a function? I guess
there is, likely a register, right?
Jan
signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
