[Xenomai] Looking for training on Linux/Xenomai on i.MX6

[Cédric Perles]

Hi,



I work for a company based in France (La-Roche-Sur-Yon) that build
embedded devices and we are planning to switch from QNX to Linux/Xenomai
on i.MX6.



I am currently searching for a training center able to teach Linux and
Xenomai to all software team (8 people).



=> Does anyone know a correct training center for this ?



=> Is there anyone experienced in Xenomai on i.MX6 (tricks, classical
traps …) ?



Regards,



Cédric


Sepro

Cédric PERLES
Software R&D engineer
SEPRO Robotique - Rue Henry Bessemer - Zone Acti-Est - CS 10084 - 85003 La
Roche sur Yon Cedex (France)

Tel : +33 (0)2 51 45 05 31

  _

  www.sepro-group.com |
 twitter@SeproGroup




-- next part --
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 22984 bytes
Desc: not available
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 818 bytes
Desc: not available
URL: 

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] Latency test fails after in a Xenomai patched Ostro XT linux distro

[Philippe Gerum]

On 03/04/2017 04:26 AM, Nitin Kulkarni wrote:
> Hi,
> 
> I have patched the Xenomai 3.0.3 to an Ostro XT linux distribution and after 
> flashing the image and booting on the Intel Joule board I installed the 
> Xenomai libraries natively. When I run the Latency test it gives this message 
> and stops.
> 
> 
> root@intel-corei7-64:~/Xenlib# /usr/xenomai/bin/latency
> == Sampling period: 100 us
> == Test mode: periodic user-mode task
> == All results in microseconds
> /usr/xenomai/bin/latency: pthread_create(latency): Operation not permitted
> 
> Although I am running as a root user it gives this error. I have not added 
> any user group through the Kernel command line parameter 
> xenomai.allowed_group?.
> when I run the command
> 
> dmesg | grep -i xenomai
> 
> 
> I get this from the Kernel log
> [0.00] Command line: rootwait console=tty0 xenomai.sysheap_size=256 
> xenomai.state=enabled xenomai.smi=detect xenomai.smi_mask=1 
> console=ttyS2,115200 video=efifb maxcpus=4 noxsave reboot=efi kmemleak=off 
> fsck.mode=skip no-ima ro root=PARTUUID=12345678-9abc-def0-0fed-cba987654321 
> rootfstype=ext4 installer
> [0.00] Kernel command line: rootwait console=tty0 
> xenomai.sysheap_size=256 xenomai.state=enabled xenomai.smi=detect 
> xenomai.smi_mask=1 console=ttyS2,115200 video=efifb maxcpus=4 noxsave 
> reboot=efi kmemleak=off fsck.mode=skip no-ima ro 
> root=PARTUUID=12345678-9abc-def0-0fed-cba987654321 rootfstype=ext4 installer
> [0.668993] [Xenomai] scheduling class idle registered.
> [0.669456] [Xenomai] scheduling class rt registered.
> [0.670016] I-pipe: head domain Xenomai registered.
> [0.672804] [Xenomai] Cobalt v3.0.3 (Groovy Cosmic Halo)

v3.0.3 is outdated, with nasty issues. You should use the latest stable
code from: git://git.xenomai.org/xenomai-3.git, branch stable-3.0.x

> 
> ?
> Please let me know how to handle this issue.

Any message visible in the kernel log after enabling
CONFIG_XENO_OPT_DEBUG_COBALT?

-- 
Philippe.

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] Latency test fails after in a Xenomai patched Ostro XT linux distro - part 2

[Philippe Gerum]

On 03/04/2017 05:30 AM, Nitin Kulkarni wrote:
> After the below things happened I added a regular user (nitin) to the 
> allowed_group parameter file in /sys/module/xenomai/parameters/allowed_group
> 
> 
> Then executed the latency test to get this message :
> 
> 
> nitin@intel-corei7-64:/usr/bin$ /usr/xenomai/bin/latency
>0"000.000| WARNING: [main] cannot open RTDM device 
> /dev/rtdm/memdev-private: Permission denied
>0"000.000| WARNING: [main] cannot map private umm area: Permission denied
>0"000.000| BUG in init_bind(): [main] (CONFIG_DEVTMPFS_MOUNT not enabled?)
> 
> ?I must be doing something wrong. Please let me know.

You need to tell udev to set appropriate permissions to the RTDM devices
via some rule file, so that users from this group may access those
devices, e.g.

# Xenomai real-time devices
SUBSYSTEM=="rtdm", MODE="0660", GROUP=

-- 
Philippe.

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] heap corruption with multiple, differently-sized calls to rt_queue_alloc()

[Philippe Gerum]

On 03/05/2017 12:43 PM, Philippe Gerum wrote:
> On 03/04/2017 03:30 AM, Josh Bowman wrote:
>> Hi,
>>
>> I'm having a problem when trying to allocate multiple blocks using
>> rt_queue_alloc(). When my client code is building a message to send to
>> queue, it sometimes finds that it needs a bigger block. So it creates a new
>> block via rt_queue_alloc(); copies the data from the previous block into
>> the new block; and then calls rt_queue_free() on the old block.
>>
>> The code included here is a simplified version of this process. It
>> allocates a buffer; puts some data in it; allocates a new buffer; and then
>> checks to make sure the previous buffer is intact. Then it frees the
>> previous buffer and loops.
>>
>> When I run this code, it prints:
>>
>> ERROR: at 7, 2: after rt_queue_alloc, checkMessage failed at loc 480
>>
>> This means the buffer previously returned by rt_queue_alloc() is damaged by
>> the next call to rt_queue_alloc().  I set a watch in the debugger, and it
>> looks like the damage is done at line 376 of lib/alchemy/queue.c; this
>> seems to indicate the heapobj_alloc() is returning a region that overlaps
>> the one previously allocated.
>>
>> I'm running Xenomai/mercury from stable-3.0.x on x86_64, with config:
>> "--with-core=mercury --enable-smp --enable-pshared --enable-registry
>> --enable-debug"
>>
>> I build the test program with:
>>
>> g++ queue-2.cpp -o queue-2 -g -fno-default-inline -fno-omit-frame-pointer
>> `xeno-config --skin=alchemy --cflags --no-auto-init --ldflags`
>>
>> Changing the realloc_count parameter causes the code to fail at different
>> iterations; passing realloc_count = 3 moves the failure to the
>> rt_queue_send() call. (The code runs to completion with realloc_count set
>> to 1 or 2.)
>>
>> I've also found that if I don't call rt_queue_free() the code runs to
>> completion.
>>
>> Let me know if there's anything I can do to help.
>>
> 
> Your test code perfectly reproduces the issue here, thanks. There is a
> severe bitmap breakage, I'm on it.
> 

Ugly bug affecting the page bitmap of the shared heap (--enable-pshared)
which caused the allocator to be terminally confused by some allocation
patterns. Fixed in the stable branch:

http://git.xenomai.org/xenomai-3.git/commit/?h=stable-3.0.x&id=027898e4732cb5de9b2f1e762a61661ba9421d00

Thanks.

-- 
Philippe.

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] heap corruption with multiple, differently-sized calls to rt_queue_alloc()

[Philippe Gerum]

On 03/04/2017 03:30 AM, Josh Bowman wrote:
> Hi,
> 
> I'm having a problem when trying to allocate multiple blocks using
> rt_queue_alloc(). When my client code is building a message to send to
> queue, it sometimes finds that it needs a bigger block. So it creates a new
> block via rt_queue_alloc(); copies the data from the previous block into
> the new block; and then calls rt_queue_free() on the old block.
> 
> The code included here is a simplified version of this process. It
> allocates a buffer; puts some data in it; allocates a new buffer; and then
> checks to make sure the previous buffer is intact. Then it frees the
> previous buffer and loops.
> 
> When I run this code, it prints:
> 
> ERROR: at 7, 2: after rt_queue_alloc, checkMessage failed at loc 480
> 
> This means the buffer previously returned by rt_queue_alloc() is damaged by
> the next call to rt_queue_alloc().  I set a watch in the debugger, and it
> looks like the damage is done at line 376 of lib/alchemy/queue.c; this
> seems to indicate the heapobj_alloc() is returning a region that overlaps
> the one previously allocated.
> 
> I'm running Xenomai/mercury from stable-3.0.x on x86_64, with config:
> "--with-core=mercury --enable-smp --enable-pshared --enable-registry
> --enable-debug"
> 
> I build the test program with:
> 
> g++ queue-2.cpp -o queue-2 -g -fno-default-inline -fno-omit-frame-pointer
> `xeno-config --skin=alchemy --cflags --no-auto-init --ldflags`
> 
> Changing the realloc_count parameter causes the code to fail at different
> iterations; passing realloc_count = 3 moves the failure to the
> rt_queue_send() call. (The code runs to completion with realloc_count set
> to 1 or 2.)
> 
> I've also found that if I don't call rt_queue_free() the code runs to
> completion.
> 
> Let me know if there's anything I can do to help.
> 

Your test code perfectly reproduces the issue here, thanks. There is a
severe bitmap breakage, I'm on it.

-- 
Philippe.

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai