headers
Nicholas Mc Guire | 18 Jun 2013 17:02
Picon

15th Real Time Linux Workshop - Call for Papers


                      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 pretty stable since the mid 80s. With the 
considerable increase of computing power, notably with multicore systems
becoming mainstream in embedded devices, the requirements on RTOS are
shifting and the tools are again trying to catch up.

In stark contrast to 1999 (when the first RTLWS took place), Linux has a 
strong position in all kind of embedded systems, ranging from consumer
electronics to network devices and a broad range of industrial applications
(Continue reading)

Permalink | Reply | 0 comments |
headers
Younes CHALABI | 18 Jun 2013 11:12
Picon

No Rootfs after installing Xenomai !

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-ipipe-3.0.36-arm-1.18-11-post.patch
          But I had so many rejects, that why I prefered to use the rel_imx_3.0.15_12.03.00 and it's advised in : xenomai-2.6.2.1/ksrc/arch/arm/patches/README
               Doing the same procedure as for linux-3.5.7, I had an uImage that I loaded on the µ-SD with the rootfs and
u-boot either with the generated files from LTIB or the L3.0.35_4.0.0_130424_images_MX6
                    THE KERNEL LAUNCH BUT DOESN'T START :
                          mmc1 is current device

                          MMC read: dev # 1, block # 2048, count 8192 ... 8192 blocks read: OK
                          ## Booting kernel from Legacy Image at 10800000 ...
                             Image Name:   Linux-$ (3.0.15_12.03.00)
                             Image Type:   ARM Linux Kernel Image (uncompressed)
                             Data Size:    3813344 Bytes =  3.6 MB
                             Load Address: 10800000
                             Entry Point:  10800000
(Continue reading)

Permalink | Reply | 2 comments |
headers
pritam munot | 18 Jun 2013 08:27
Picon
Favicon

Xenomai port on IMX28.

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
Permalink | Reply | 0 comments |
headers
Younes CHALABI | 17 Jun 2013 16:13
Picon

Xenomai-2.6.2.1 with a kernel-3.0.15 Freescale Release on i.MX6Q Sabre Lite Booting problem

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" --build=i686-pc-linux-gnu --host=arm-none-linux-gnueabi
 8- make DESTDIR=$staging_dir install

Then putting the build_root/linux/arch/arm/boot/uImage | System.map | modules.builtin |  
modules.order |  Module.symvers      ==> to /media/boot

But when booting the target the kernel doesn't start and have this display :

 mmc1 is current device

 MMC read: dev # 1, block # 2048, count 8192 ... 8192 blocks read: OK
 ## Booting kernel from Legacy Image at 10800000 ...
   Image Name:   Linux-$ (3.0.15_12.03.00)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Leopold Palomo-Avellaneda | 17 Jun 2013 15:26

Using modern adeos patch with older xenomai version

Hi,

can I use ipipe-core-3.5.7 adeos patch with xenomai 2.5.6?

Regards,

Leo

--

-- 
--
Linux User 152692
Catalonia
Permalink | Reply | 2 comments |
headers
HAUTBOIS Flavian | 17 Jun 2013 09:54
Picon
Favicon

CPU time limit exceeded

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:200
    #6  0xb43cc282 in ec_config_init (usetable=0 '\000') at /home/alex/ros_workspace/orocos/soem/soem_core/build/soem_core/src/ethercatconfig.c:162
    #7  0xb4413fb1 in soem_master::SoemMasterComponent::configureHook (this=0x887d648) at /home/alex/ros_workspace/orocos/soem/soem_master/soem_master_component.cpp:73

Now the weird part. There are two libraries that are generated. The first one is soem_core, and the second
one is soem_master (if you dig into the source code you may find it's a little bit more complex).

There is one executable which uses soem_core, and it succeeds in sending an EtherCAT frame through RTNet
without any problems.
The soem_master library also depends on soem_core and uses _exactly_ the same functions as the above
executable, _in the same order_. The only difference is that the soem_master lib is fed to Orocos (a
robotic real-time middleware, not sure this is very important here though) to execute a
Master.configure() function (if you were wondering where the configureHook came from). However, it
crashes when executing the "send" function (see the bt). It is worth noting that Wireshark detects that
one EtherCAT frame is send when using this method (it crashes right after). It is also worth noting that
everything is built using the ROS build system.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Manuel Huber | 16 Jun 2013 23:04
Picon

rtdm: minimal patch for sys_rtdm_recvmsg

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&forum_name=rtnet-developers 
<http://sourceforge.net/mailarchive/forum.php?thread_name=51BAB330.70500%40web.de&forum_name=rtnet-developers>

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 and msg_controllen has to be set to the
    number of bytes written to the control message buffer rather than the
    space left.
6. Back to user space.

Current implementation could cause problems: Control messages are
currently not used but the msg_controllen field inidicates that control
messages have been written to the buffer; I'm not sure that this is a
(Continue reading)

Permalink | Reply | 3 comments |
headers
alex alex | 13 Jun 2013 23:29
Picon

IgH EtherCAT Master & xenomai posix skin

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 (& þáttr);
     pthread_attr_setdetachstate (& þáttr, PTHREAD_CREATE_JOINABLE);
     pthread_attr_setinheritsched (& þáttr, PTHREAD_EXPLICIT_SCHED);
     pthread_attr_setschedpolicy (& þáttr, SCHED_FIFO);
     pthread_setschedparam (cyclicthread, SCHED_FIFO, & param);
     pthread_set_name_np (cyclicthread, "ec_xenomai_posix_test");
     ret = pthread_create (& cyclicthread, & þáttr, & 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 :

     / * Create cyclic RT-thread * /
     param = {struct sched_param sched_priority = 82.};
     pthread_attr_t þáttr;
(Continue reading)

Permalink | Reply | 0 comments |
headers
alex alex | 13 Jun 2013 23:06
Picon

Ethercat & ARM

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
Permalink | Reply | 0 comments |
headers
Tom Philips | 13 Jun 2013 16:07
Picon

[xenomai-forge] psos interface: t_setpri keeps threadobj mutex locked

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->status & __THREAD_S_NOPREEMPT) {
    thobj->core.prio_unlocked = prio;
    thobj->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
Permalink | Reply | 1 comment |
headers
Jan Kiszka | 12 Jun 2013 08:15
Picon

[PATCH] posix: Skip auto-shadowing if current thread is already shadowed

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 <jan.kiszka <at> siemens.com>
---
 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
 <at>  <at>  -31,6 +31,7  <at>  <at> 
 #include <rtdk.h>

 #include <asm-generic/xenomai/bind.h>
+#include <asm-generic/xenomai/current.h>

 int __pse51_muxid = -1;
 int __pse51_rtdm_muxid = -1;
 <at>  <at>  -67,7 +68,7  <at>  <at>  static __constructor__ void __init_posix_interface(void)
 	}

 	noshadow = getenv("XENO_NOSHADOW");
-	if (!noshadow || !*noshadow) {
+	if ((!noshadow || !*noshadow) && xeno_get_current() == XN_NO_HANDLE) {
(Continue reading)

Permalink | Reply | 3 comments |

Gmane