http://blog.gmane.org/gmane.linux.real-time.xenomai.users hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.linux.real-time.xenomai.users/16974 <pre> 15th Real Time Linux Workshop 1st Call for Papers October 28 - 31, 2013 Dipartimento tecnologie innovative Scuola universitaria professionale della Svizzera italiana Lugano-Manno Switzerland Following the meetings of academics, developers and users of real-time and embedded Linux at the previous 14 Real Time Linux Workshops held world-wide (Vienna, Orlando, Milano, Boston, Valencia, Singapore, Lille, Lanzhou, Linz, Guadalajara, Dresden, Nairobi, Prague and Chapel Hill) - the 2013 Real Time Linux Workshop will come to the Scuola Universitaria Professionale della Svizzera Italiana in Lugano-Manno, Switzerland. It will be held from October 28 to October 31, 2013. Rationale Real-time systems have evolved over the past decades in a relatively calm manner - performance has increased, one can say dramatically, but the main paradigms were pret</pre> Nicholas Mc Guire 2013-06-18T15:02:01 http://comments.gmane.org/gmane.linux.real-time.xenomai.users/16973 <pre>Hi, I want to install xenomai on the i.MX6Q Sabre Lite board, for this I followed differents strategies but still not able to have xenomai on the target. 1- linux-3.5.7 vs xenomai-2.6.2.1 vs ipipe-core-3.5.7-arm-3.patch : Using the installation procedure for ARM from : www.xenomai.org/documentation/xenomai-2.6/html/README.INSTALL/ The problem with this strategy is that I hadn't a rootfs to boot the target, so I took a different strategy. HOW CAN I HAVE A ROOTFS TO BOOT THE TARGET WITH THE COMPILED SOURCES ? 2- Using the L3.0.35_4.0.0_130424 Freescale Release I built LTIB and by the way a rootfs, an uImage and a u-boot.bin which work correctly on the target. Once having the rootfs I wanted to build the kernel patching it with xenomai and using the previous rootfs (LTIB) PATCHING FAILED 3- I tried to patch the linux-3.0.35 with : adeos-ipipe-3.0.36-arm-1.18-11-pre.patch | adeos-ipipe-3.0.36-arm-1.18-11.patch | adeos-ip</pre> Younes CHALABI 2013-06-18T09:12:29 http://comments.gmane.org/gmane.linux.real-time.xenomai.users/16972 <pre>Hello All, I am new to Xenomai and trying to find information about running QT and Xenomai on IMX28. On http://www.xenomai.org/index.php/Embedded_Device_Support#Supported_SoC, I can see Xenomai port already exist for IMX28. I have a IMX28 based development board TQMA28, its running Linux 2.6.35 and Linux 3.5. I am trying to find information on how to run Xenomai on the development board. http://www.xenomai.org/index.php/Xenomai_quick_build_quide tell how to build xenomai. I am trying to understand how it will get information about linux kernel which came along with the board. I am bit confused with Patch the kernel section. Will this patch linux kernel 2.6.35 or 3.5 which came along with the board. After patching which kernel do i compile xenomai kernel or linux kernel which came along with the board. Can some one please share some information or give some pointers to information. Thanks Tama </pre> pritam munot 2013-06-18T06:27:27 http://comments.gmane.org/gmane.linux.real-time.xenomai.users/16970 <pre>Hi, I'm trying to install xenomai-2.6.2.1 on the i.MX6Q Sabre Lite. Using U-boot-mx6q-sabrelite.bin and the rootfs.ext2 from the L3.0.35_4.0.0_130424_images_MX6 directory. The kernel used is rel_imx_3.0.15_12.03.00, and after patching it with xenomai-2.6.2.1 following these steps : 1- Applying xenomai-2.6.2.1/ksrc/arch/arm/patches/mxc/adeos-ipipe-3.0.36-arm-1.18-11-pre.patch 2- Applying xenomai-2.6.2.1/ksrc/arch/arm/patches/adeos-ipipe-3.0.36-arm-1.18-11.patch 3- Applying xenomai-2.6.2.1/ksrc/arch/arm/patches/mxc/adeos-ipipe-3.0.36-arm-1.18-11-post.patch 4- xenomai-2.6.2.1/scripts/prepare-kernel.sh --arch=arm --adeos=$xenomai_root/ksrc/arch/arm/patches/adeos-ipipe-3.0.36-arm-1.18-11.patch --linux=rel_imx_3.0.15_12.03.00 5- make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- O=$build_root/linux imx6_defconfig 6- make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- O=$build_root/linux bzImage modules 7- xenomai-2.6.2.1/configure CFLAGS="-march=armv7-a -mfpu=vfp3" FDFLAGS="-march=armv7-a -mfpu=vfp3" -</pre> Younes CHALABI 2013-06-17T14:13:53 http://comments.gmane.org/gmane.linux.real-time.xenomai.users/16968 <pre>Hi, can I use ipipe-core-3.5.7 adeos patch with xenomai 2.5.6? Regards, Leo </pre> Leopold Palomo-Avellaneda 2013-06-17T13:26:01 http://comments.gmane.org/gmane.linux.real-time.xenomai.users/16965 <pre>Hello, I'm having a 'CPU time limit exceeded' error. Of course I tried to set ulimit to unlimted, without any success. I am running a program that uses RTNet over Xenomai 2.6.2. The source of the program can be found here: git.mech.kuleuven.be/robotics/soem.git Here is the core dump backtrace: #0 0xb77b8424 in __kernel_vsyscall () #1 0xb5c03c2c in __wrap_send () from /usr/xenomai/lib/libpthread_rt.so.1 #2 0xb43d2a93 in ec_outframe (idx=1 '\001', stacknumber=0) at /home/alex/ros_workspace/orocos/soem/soem_core/build/soem_core/src/nicdrv.c:404 #3 0xb43d2b28 in ec_outframe_red (idx=1 '\001') at /home/alex/ros_workspace/orocos/soem/soem_core/build/soem_core/src/nicdrv.c:427 #4 0xb43d3248 in ec_srconfirm (idx=1 '\001', timeout=20000) at /home/alex/ros_workspace/orocos/soem/soem_core/build/soem_core/src/nicdrv.c:702 #5 0xb43c9839 in ec_BRD (ADP=0, ADO=0, length=2, data=0xbffd53a6, timeout=20000) at /home/alex/ros_workspace/orocos/soem/soem_core/build/soem_core/src/ethercatbase.c:2</pre> HAUTBOIS Flavian 2013-06-17T07:54:44 http://comments.gmane.org/gmane.linux.real-time.xenomai.users/16960 <pre>Hello! I plan to add a minor change to RTnet which allows to get reception timestamps through recvmsg: SO_TIMESTAMPNS patch: http://sourceforge.net/mailarchive/forum.php?thread_name=51BAB330.70500%40web.de&amp;forum_name=rtnet-developers &lt;http://sourceforge.net/mailarchive/forum.php?thread_name=51BAB330.70500%40web.de&amp;forum_name=rtnet-developers&gt; Current implementation (of RTDM) in RTAI and Xenomai doesn't fix the msg_control and msg_controllen field in struct msghdr. I believe, it should be done similar to the linux kernel: 1. User specifies how much space has been allocated for control messages - msg_control is set to starting address of buffer - msg_controllen is set to the size of the buffer 2. User calls recvmsg 3. Control messages are tried to be inserted by some kernel code 4. msg_control is set to the next free byte, msg_controllen is updated to the actual space left in the buffer. 5. Before copying the struct to the user, msg_control has to be reset to the actual starting address an</pre> Manuel Huber 2013-06-16T21:04:25 http://comments.gmane.org/gmane.linux.real-time.xenomai.users/16958 <pre>xenomai:2.6.2.1 linux:3.5.7 IgH EtherCAT : latest version rt ethernet driver:e1000e Hello everyone, Are there people who have succeeded in obtaining a real-time behavior with xenomai posix skin using real-time drivers? I tried to run the posix skin example, but the implementation is quitestrange : / * Create cyclic RT-thread * / param = {struct sched_param sched_priority = 82.}; pthread_attr_t þáttr; pthread_attr_init (&amp; þáttr); pthread_attr_setdetachstate (&amp; þáttr, PTHREAD_CREATE_JOINABLE); pthread_attr_setinheritsched (&amp; þáttr, PTHREAD_EXPLICIT_SCHED); pthread_attr_setschedpolicy (&amp; þáttr, SCHED_FIFO); pthread_setschedparam (cyclicthread, SCHED_FIFO, &amp; param); pthread_set_name_np (cyclicthread, "ec_xenomai_posix_test"); ret = pthread_create (&amp; cyclicthread, &amp; þáttr, &amp; my_thread, NULL); The result is that the cyclic task is not real-time because it uses " pthread_setschedparam" before the thread is created. After correcting this with : </pre> alex alex 2013-06-13T21:29:56 http://comments.gmane.org/gmane.linux.real-time.xenomai.users/16957 <pre>Hello everyone, I would like to use EtherCAT with an Arm board and I wonder if there already were people who did this? or even just used RTnet with ARM? If yes, I would like some feedback about what performances you obtained, library used (etherlab, soem) and ethernet drivers used...? Thanks and regards, Alexandre </pre> alex alex 2013-06-13T21:06:36 http://comments.gmane.org/gmane.linux.real-time.xenomai.users/16955 <pre>There seems to be a mutex problem when using psos call t_setpri() There is one case where a threadobj_lock() is not matched with a threadobj_unlock() Here's the normal call sequence: +++ t_setpri() get_psos_task_or_self() threadobj_lock() threadobj_set_priority() threadobj_unlock() +++ But in threadobj_set_priority() (Mercury version), the case below has no threadobj_unlock() +++ if (thobj-&gt;status &amp; __THREAD_S_NOPREEMPT) { thobj-&gt;core.prio_unlocked = prio; thobj-&gt;core.policy_unlocked = prio ? SCHED_RT : SCHED_OTHER; /****** No threadobj_unlock() *****/ return 0; } +++ This causes other threads to hang on a threadobj_lock() Regards, Tom </pre> Tom Philips 2013-06-13T14:07:47 http://comments.gmane.org/gmane.linux.real-time.xenomai.users/16948 <pre>While the user can also avoid double shadowing by providing the XENO_NOSHADOW environment variable, there is still no reason to attempt auto-shadowing in their absence if the current thread is already a Xenomai thread. This helps, e.g., in complex dlopen scenarios where the POSIX lib is pulled in belatedly, potentially after some other lib already shadowed the dlopen caller. Signed-off-by: Jan Kiszka &lt;jan.kiszka&lt; at &gt;siemens.com&gt; --- src/skins/posix/init.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/src/skins/posix/init.c b/src/skins/posix/init.c index 80725c5..ca1d9e1 100644 --- a/src/skins/posix/init.c +++ b/src/skins/posix/init.c &lt; at &gt;&lt; at &gt; -31,6 +31,7 &lt; at &gt;&lt; at &gt; #include &lt;rtdk.h&gt; #include &lt;asm-generic/xenomai/bind.h&gt; +#include &lt;asm-generic/xenomai/current.h&gt; int __pse51_muxid = -1; int __pse51_rtdm_muxid = -1; &lt; at &gt;&lt; at &gt; -67,7 +68,7 &lt; at &gt;&lt; at &gt; static __constructor__ void __init_posix_interface(void) } noshadow = getenv("XENO_NOSHADOW"); -if (!noshadow || !*noshadow) { +if ((!noshadow || !*nos</pre> Jan Kiszka 2013-06-12T06:15:40 http://comments.gmane.org/gmane.linux.real-time.xenomai.users/16935 <pre>Hi all, I've merged 3.8.13 into our stable 3.8 branch. This triggered some minor conflicts in generic and ARM code. Please see git://git.xenomai.org/ipipe-jki for-upstream/3.8 for details. The result works fine for x86, and if it's also OK for the other arch, I'd propose this to be merged into the official 3.8 stable branch. Jan </pre> Jan Kiszka 2013-06-11T14:28:49 http://comments.gmane.org/gmane.linux.real-time.xenomai.users/16926 <pre>Hello We have observed that the SM_NOWAIT flag is not taken into account for the sm_p service call. If the sm_p is called with the SM_NOWAIT flag and a timeout of 0, the call never returns while it is expected that the timeout value is not taken into account at all. This is solved with the attached patch. --- Ronny -------------- next part -------------- A non-text attachment was scrubbed... Name: semaphore-apply-nowait-flag.patch Type: application/octet-stream Size: 647 bytes Desc: not available URL: &lt;http://www.xenomai.org/pipermail/xenomai/attachments/20130611/df8620cb/attachment.obj&gt; </pre> Ronny Meeus 2013-06-11T10:22:52 http://comments.gmane.org/gmane.linux.real-time.xenomai.users/16916 <pre>Now I use Imx53 gpio2-14 to be a interrupt source ,but I found its priority so lower . So I use tzic_set_irq_prio(int irq, int hi) ................................. ............................. MY_GPIO2_14=(1*32+14)+128; irq=irq_ to_gpio( MY_GPIO2_14); mxc_tzic_init_irq(IMX53_TZIC_BASE_ADDR); tzic_set_irq_prio(irq,20);//chang the priority to #30 ................................. ...................................... Is it right？ _______________________________________________ Xenomai mailing list Xenomai&lt; at &gt;xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai </pre> 嵌入式工程师 2013-06-08T15:40:54 http://comments.gmane.org/gmane.linux.real-time.xenomai.users/16912 <pre>Hi, I'm new to xenomai and I just installed it with Ubuntu 13.04 and kernel 3.5.7. As soon as I booted 3.5.7 with xenomai, the Unity GUI stopped working. It looks like the problem is in compiz, a plugin for Unity. Unity can't run without it. I'm getting the exact same problem on Ubuntu 13.04 on a macbook and a Dell desktop. Has anyone else run across this problem? I can still run xenomai code through the terminal and I can run graphics applications, but if I try to load compiz the whole system freezes. It looks like compiz is persistently broken, because when I reboot into the 3.8.0 kernel that comes with Ubuntu 13.04, Unity/compiz are still broken. Any thoughts? Thanks </pre> Travis Llado 2013-06-07T01:28:02 http://comments.gmane.org/gmane.linux.real-time.xenomai.users/16907 <pre>just letting you know I'm working with Robert Nelson to tack on a Xenomai kernel build to his automated build the thread is here: http://eewiki.net/display/linuxonarm/BeagleBone+Black+Comments (cant link to the actual post, search for xenomai) this flow already produces the vanilla kernels which are in the BB Ubuntu and Debian images; the process is outlined here: http://tinyurl.com/n5ly89t ; the xenomai kernel(s) would be tacked onto this stream: http://rcn-ee.net/deb/wheezy-armhf/ for now I'll use the patches Stephan had forwarded me in private, and switch on next release (suggestions to do better than that welcome) - Michael </pre> Michael Haberler 2013-06-05T15:42:16 http://comments.gmane.org/gmane.linux.real-time.xenomai.users/16903 <pre> A bad bug has been fixed in the unlocked context switching code for powerpc platforms. This affects all I-pipe patches for 3.4 kernels and above. The typical manifestation of this bug is random segmentation faults in user-space applications (sometimes after hours under stress load), usually the Xenomai-dependent ones. A work around not to change the kernel code is to disable CONFIG_XENO_HW_UNLOCKED_SWITCH. Patches for fixing this issue are available for 3.5.7 and above: http://git.xenomai.org/?p=ipipe.git;a=commit;h=614aa59453dacf7693fbb18229c27676c2803dbb http://git.xenomai.org/?p=ipipe.git;a=commit;h=04ea520ab96a16ec65529a2efed92c9a4a8bda34 You might need this companion patch too: http://git.xenomai.org/?p=ipipe.git;a=commit;h=047a21b3b203a1fbfce21284f01e376a2cf54c19 HTH, </pre> Philippe Gerum 2013-06-05T10:39:29 http://comments.gmane.org/gmane.linux.real-time.xenomai.users/16888 <pre>Hello we are currently running with recent version of xenomai-forge. The issue we see is a crash while running the attached application code (pSOS interface). Basically the test creates a number of "chained" (called batches) tasks. After setting up the batch, the first task starts a timer and when the timer expires, an event is sent to the next task in the chain. This process continues forever. If only 1 chain is created we do not see issues. The number of threads in the chain is less relevant since typically there will be no big impact when the number of tasks increases. When we start to increase the number of batches we start to see crashes. For example in the test below we create 20 batches with 1 thread in each batch. The -o parameter specifies the timeout used by the timer of each task before the control is given to the next task in the chain. ulimit -s 128 ;taskset 2 ./tests -t 1 -b 20 -o 1 Xenomai test: threads 1, batches 20, timeout 1 ms, stats 0 thread_entry(0,0) thread_entry(1,0) thread_entry(</pre> Ronny Meeus 2013-06-04T10:56:26 http://comments.gmane.org/gmane.linux.real-time.xenomai.users/16879 <pre>Hi, I've a little problem. When I try to compile my code with my new system (xenomai 2.6.2.1) I get the following error: gcc: error: ;-Wl,&lt; at &gt;/usr/xenomai/lib/posix.wrappers: No such file or directory The file posix.wrappers exits in the /usr/xenomai/lib-directory. Futhermore, if move this file to anywhere else I get this message: /home/profit/Work/Development/bv_ProFIT_guidePC_shared/bin/libkogmo_rtdb.so: undefined reference to `pthread_mutexattr_settype' /home/profit/Work/Development/bv_ProFIT_guidePC_shared/bin/libkogmo_rtdb.so: undefined reference to `clock_gettime' /home/profit/Work/Development/bv_ProFIT_guidePC_shared/bin/libkogmo_rtdb.so: undefined reference to `pthread_condattr_setpshared' /home/profit/Work/Development/bv_ProFIT_guidePC_shared/bin/libkogmo_rtdb.so: undefined reference to `pthread_mutexattr_setprotocol' /home/profit/Work/Development/bv_ProFIT_guidePC_shared/bin/libkogmo_rtdb.so: undefined reference to `shm_unlink' /home/profit/Work/Development/bv_ProFIT_guidePC_shared/bin/libkogmo_</pre> Franz Engel 2013-06-03T16:50:40 http://comments.gmane.org/gmane.linux.real-time.xenomai.users/16867 <pre>In xenomai gpio interrupt priority and task priority which is is higher? </pre> 嵌入式工程师 2013-06-01T09:09:09 http://comments.gmane.org/gmane.linux.real-time.xenomai.users/16866 <pre>I have try the kernal-3.4.6 with ipipe-core-3.4.6-arm-4.patch when I set three same Priority tasks I found untill the tasks stop ,the interrut founction will not run. It same like before version kernal-2.6.35.9 with ipipe-core-2.6.35.9-arm-4.patch static int test_thread(void *data) { //phase=ctrl_mnm1221_m(); while(1) { if(flag) { printk("runting %lld\n",tt3); flag=0; } SLEEP_MILLI_SEC(50); } return 0; } int irq_handle_function(int irq, void *device_id) { //if(phase==PH_RUNNING) //ctrl_mnm1221_m(); rt_intr_disable(&amp;amp;intr_desc); tt1=rt_timer_read(); tt3=tt1-tt2; if(tt3&amp;gt;300000) flag=1; tt2=tt1; rt_intr_enable(&amp;amp;intr_desc); return RT_INTR_HANDLED;; } void taskOne(void*arg) { int i; for (i=0; i &amp;lt; 0xffff; i++) { printk("Iam taskOneand global = %d................\n", tt3); } } void taskTwo(void*arg) { int i; for (i=0; i &amp;lt; 0xffff; i++) { printk("Iam taskTwo global = %d................\n", tt3); } } void taskThree(void*arg) { int i; for (i=0; i &amp;lt; 0xff</pre> 嵌入式工程师 2013-06-01T08:43:51 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.linux.real-time.xenomai.users