[Xenomai] (no subject)

[Xenomai] (no subject)

[Amit Bhaira]

We are writing a rtdm driver for pci das card, its getting an irq line
shared with a linux kernel device i.e uhci_hcd:usb3.
Can we disable the irq line in our driver? Or shall we disable the
particular usb driver?
Or would u suggest any other solution coz our driver is making the
system unresponsive?. Or is there any way to get an independent irq
line for my device.

Re: [Xenomai] (no subject)

[Gilles Chanteperdrix]

On 01/26/2013 10:44 AM, Amit Bhaira wrote:

> We are writing a rtdm driver for pci das card, its getting an irq line
> shared with a linux kernel device i.e uhci_hcd:usb3.
> Can we disable the irq line in our driver?


Yes, but what would be the purpose of doing that?

> Or shall we disable the particular usb driver?


If you want to use the IRQ in the RTDM driver, you will have to do that.

> Or would u suggest any other solution coz our driver is making the
> system unresponsive?. Or is there any way to get an independent irq
> line for my device.


See:
http://xenomai.org/index.php/FAQs#What_can_I_do_if_Xenomai_and_Linux_devices_share_the_same_IRQ.3F

-- 
                                                                Gilles.

[Xenomai] (no subject)

[rajae rajae]

please to uninstall xenomai or reconfigure it ,because it sounds like there
is a problem in the configuration so that when I execute ./latency I got
just the first three lines
== Sampling period: 100 us
== Test mode: periodic user-mode task
== All results in microseconds

Re: [Xenomai] (no subject)

[Greg Gallagher]

How did you install it in the first place? What platform are you using? X86, arm, ppc??

  Original Message  
From: samiraelmadani9@gmail.com
Sent: December 17, 2017 11:49 AM
To: xenomai@xenomai.org
Subject: [Xenomai] (no subject)

please to uninstall xenomai or reconfigure it ,because it sounds like there
is a problem in the configuration so that when I execute ./latency I got
just the first three lines
== Sampling period: 100 us
== Test mode: periodic user-mode task
== All results in microseconds
_______________________________________________
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

[Xenomai] (no subject)

[Xu Chen]

Hi, all guys,
We tested the 64-bit  Xenomai. Here are our results:


Xenomai Latency:  [cid:image001.png@01D320E9.A1940EA0]           Xenomai Autotune :  [cid:image002.png@01D320E9.A1940EA0]
Is there a way to tune Xenomai to reduce the jitter in the User Space task latency ?
Best Regards
Xu chen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 9876 bytes
Desc: image001.png
URL: <http://xenomai.org/pipermail/xenomai/attachments/20170829/e448918c/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 10211 bytes
Desc: image002.png
URL: <http://xenomai.org/pipermail/xenomai/attachments/20170829/e448918c/attachment-0001.png>

[Xenomai] (no subject)

[Umair Ali]

Hello Xenomai team,

I am working on sending the raw Ethernet packets through RTnet driver (rt_8139t). I am using the the example i.e. raw-ethernet.c as my starting point for sending the raw Ethernet packets from Rtnet source file. I have managed to compile the using skin=Posix and also able run it with rteth0 interface. The code file is attached with this email along with makefile. I have configured the rteth0 interface with ip and netmask with promisc mode. Morover over i have added the route by using the command "./rtroute solicit 10.0.0.11 dev rteth0". I am able to ping also as below:

root@cpc:/usr/xenomai/sbin# ./rtping 10.0.0.11
Real-time PING 10.0.0.11 56(84) bytes of data.
ioctl: No route to host
root@cpc:/usr/xenomai/sbin# ./rtroute solicit 10.0.0.11 dev rteth0
root@cpc:/usr/xenomai/sbin# ./rtping 10.0.0.11
Real-time PING 10.0.0.11 56(84) bytes of data.
64 bytes from 10.0.0.11: icmp_seq=1 time=408.6 us
64 bytes from 10.0.0.11: icmp_seq=2 time=370.1 us
64 bytes from 10.0.0.11: icmp_seq=3 time=387.2 us
64 bytes from 10.0.0.11: icmp_seq=4 time=413.4 us
^C
--- 10.0.0.11 rtping statistics ---
4 packets transmitted, 4 received, 0% packet loss
worst case rtt = 413.4 us"

The other PC is non real time windows PC. And I can see the ping traffic on the windows PC. But when i run the code after compilation I can not see the traffic on the network. The output of the code is

root@cpc:/usr/xenomai# ./raw_packet rteth0 aliumair
sock: 3
string copy: rteth0
ioctl:  0
addr.sll_family: 17
addr.sll_protocol: 13330
addr.sll_ifindex: 1
Sent frame of 1514 bytes
Sent frame of 1514 bytes

My first question is what i am doing wrong due to which i am able to see the traffic on the network even though i can see the ping traffic.

Now my second problem is when i am running the code after the compilation and look a the threads with output such as

root@cpc:/home/cpc# cat /proc/xenomai/sched/threads
CPU  PID    CLASS  TYPE      PRI   TIMEOUT       STAT       NAME
  0      0          idle       core       -1           -                     R          [ROOT/0]
  1      0          idle       core       -1           -                     R          [ROOT/1]
  0      405        rt         core       98           -                    W          [rtnet-stack]
  0      406        rt         core        0           -                     W          [rtnet-rtpc]
  1      2282       rt         core        0           -                    W          [rtnetproxy]
  0      2737       rt         cobalt    100   140ms47us       D          raw_packet
root@cpc:/home/cpc# cat /proc/xenomai/sched/threads
CPU  PID    CLASS  TYPE      PRI   TIMEOUT       STAT       NAME
  0      0        idle       core           -1           -                 R          [ROOT/0]
  1      0        idle       core           -1           -                 R          [ROOT/1]
  0      405    rt         core           98            -                 W          [rtnet-stack]
  0      406    rt         core            0            -                 W          [rtnet-rtpc]
  1      2282  rt         core            0            -                 W          [rtnetproxy]
  0      2737  rt         cobalt        100   924ms122us    D          raw_packet

I have found that the time out for the raw_packet thread is varying. I think if the the thread is running in real time it should be constant and deterministic. So Please guide me if i am missing anything.

Details of my setup are
root@cpc:/home/cpc# dmesg | grep xenomai
[    0.000000] Linux version 3.14.39-xenomai-3.0.1 (root@cpc) (gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04) ) #2 SMP PREEMPT Tue Nov 10 18:02:47 EET 2015
[    0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.14.39-xenomai-3.0.1 root=UUID=e29fa266-6a54-4815-b5bd-ea0168f18fd7 ro quiet splash crashkernel=384M-:128M vt.handoff=7
[    0.836257]           (see xenomai.smi parameter). You might encounter
[    1.640220] usb usb1: Manufacturer: Linux 3.14.39-xenomai-3.0.1 ehci_hcd
[    1.641529] usb usb2: Manufacturer: Linux 3.14.39-xenomai-3.0.1 uhci_hcd
[    1.642402] usb usb3: Manufacturer: Linux 3.14.39-xenomai-3.0.1 uhci_hcd
[    1.643256] usb usb4: Manufacturer: Linux 3.14.39-xenomai-3.0.1 uhci_hcd
[    1.644153] usb usb5: Manufacturer: Linux 3.14.39-xenomai-3.0.1 uhci_hcd

And i have run all the modules in order to make the rteth0 to be up as explained in the link
https://sir.upc.edu/wikis/roblab/index.php/Development/RTnet

Thanks in advance

Best regards
Ali





-------------- next part --------------
A non-text attachment was scrubbed...
Name: raw_packet.c
Type: text/x-csrc
Size: 3667 bytes
Desc: raw_packet.c
URL: <http://xenomai.org/pipermail/xenomai/attachments/20151125/8aba3db9/attachment.c>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: makefile
Type: application/octet-stream
Size: 2319 bytes
Desc: makefile
URL: <http://xenomai.org/pipermail/xenomai/attachments/20151125/8aba3db9/attachment.obj>

[Xenomai] (no subject)

[‫Mohamed Fawzy‬ ‫]

i followed  documentation to  get xenomai up and running on a udoo board 
but when i run the latency test i get this error message : Xenomai: native skin or CONFIG_XENO_OPT_PERVASIVE disabledwhen i check  Troubleshooting guide i found that i should have /proc/xenomai/version but in my udooubuntu the folder proc is empty 
please i need your help to fix this problem and how i can check that xenomai is running on my board 
Regards , Mohamed Fawzy

Re: [Xenomai] (no subject)

[Nicolas SCHURANDO]

Hi Mohamed,

What version of xenomai are you using ? I am going to assume 2.6.x. I
haven't worked with 3.x yet, and its architecture being different, I don't
think the following instructions would apply for it.

Installation of xenomai as explained at
http://www.xenomai.org/documentation/xenomai-head/pdf/README.INSTALL.pdf is
achieved through these steps :

   1. If you are using a non-vanilla kernel, you should check for a
   possible pre-patch specific for your kernel.

   2. Prepare your kernel by using the prepare-kernel.sh script.

   3. Again, if you are using a non-vanilla kernel, check for a possible
   post-patch to apply.

   4. Configure your kernel as you would normally do, through "make
   menuconfig" for example, and ensure the chosen configuration complies with
   xenomai requirements; see chapter "Kernel configuration" of
   http://www.xenomai.org/documentation/xenomai-head/pdf/TROUBLESHOOTING.pdf

   5. Build your kernel, its modules, and deploy them on your target. At
   this point, you should see a few lines during early boot process if you
   type "dmesg | grep -i xenomai".

   6. Finally, build the user-space binaries of xenomai, and deploy them on
   your target.

Maybe someone can correct me if I am wrong, but I believe the
"/proc/xenomai/version" pseudo-file is provided by the kernel, not by the
user-space binaries. So, if it is missing on your board, it means something
went wrong somewhere between steps 1 and 5.

Have you cross-compiled for the correct arch ? Providing us with the
content of your dmesg would be a starting point.

Regards,

Nicolas Schurando

2015-08-19 13:58 GMT+02:00 <m.fawzy307@yahoo.com>:

> i followed  documentation to  get xenomai up and running on a udoo board
> but when i run the latency test i get this error message : Xenomai: native
> skin or CONFIG_XENO_OPT_PERVASIVE disabledwhen i check  Troubleshooting
> guide i found that i should have /proc/xenomai/version but in my udooubuntu
> the folder proc is empty
> please i need your help to fix this problem and how i can check that
> xenomai is running on my board
> Regards , Mohamed Fawzy
> _______________________________________________
> Xenomai mailing list
> Xenomai@xenomai.org
> http://xenomai.org/mailman/listinfo/xenomai
>

-- 


Avant d'imprimer ce document, pensez à l'environnement !

Always think green before printing !

Ce courriel et toutes ses pièces jointes sont confidentiels et destinés 
exclusivement à l'usage de la personne à laquelle ils sont adressés. Si 
vous n 'êtes pas le destinataire, nous vous informons que toute 
utilisation, modification, diffusion, édition ou reproduction (totale ou 
partielle) de ce courriel et/ou de ses pièces jointes, ou des informations 
qu'ils contiennent, sous quelque forme que ce soit, est strictement 
interdite. Si vous avez reçu ce courriel par erreur, merci immédiatement 
d'avertir l'expéditeur et de le supprimer avec ses pièces jointes ainsi que 
toute copie, de votre système informatique. Nous ne pouvons assurer la 
sécurité des informations transmises par voie électronique. Nous déclinons 
donc toute responsabilité dans l'hypothèse ou ce courriel et/ou ses pièces 
jointes auraient été notamment modifiés, altérés et/ou en cas de 
transmission d'un virus. Par conséquent, en communiquant avec nous vous 
acceptez ces risques. Nous vous conseillons de vérifier l'absence de virus 
dans ce courriel et ses pièces jointes.

This e-mail and its attachments are confidential and intended for use by 
the above named recipient(s) only. If you are not the intended recipient, 
please note that any use, modification, dissemination, edition or 
reproduction (either in whole or partially) of this e-mail and/or its 
attachments, or of the information contained herein, is strictly 
prohibited. If you have received this e-mail by mistake, please notify the 
sender immediately, and immediately delete this e-mail with its attachments 
and any copy of it from your computer system. We do not ensure the security 
of electronically transmitted information. Therefore, we take no 
responsibility in the event this email and/or its attachments may have been 
for example modified, altered and/or in the case of transmission of a 
virus. Your communication with us through such means shall signify your 
acceptance of such risks. We kindly advise you to check whether this email 
or its attachments are free of viruses.

Re: [Xenomai] (no subject)

[Gilles Chanteperdrix]

On Fri, Aug 21, 2015 at 11:18:47AM +0200, Nicolas SCHURANDO wrote:
> Hi Mohamed,
> 
> What version of xenomai are you using ? I am going to assume 2.6.x. I
> haven't worked with 3.x yet, and its architecture being different, I don't
> think the following instructions would apply for it.
> 
> Installation of xenomai as explained at
> http://www.xenomai.org/documentation/xenomai-head/pdf/README.INSTALL.pdf is
> achieved through these steps :
> 
>    1. If you are using a non-vanilla kernel, you should check for a
>    possible pre-patch specific for your kernel.
> 
>    2. Prepare your kernel by using the prepare-kernel.sh script.
> 
>    3. Again, if you are using a non-vanilla kernel, check for a possible
>    post-patch to apply.
> 
>    4. Configure your kernel as you would normally do, through "make
>    menuconfig" for example, and ensure the chosen configuration complies with
>    xenomai requirements; see chapter "Kernel configuration" of
>    http://www.xenomai.org/documentation/xenomai-head/pdf/TROUBLESHOOTING.pdf
> 
>    5. Build your kernel, its modules, and deploy them on your target. At
>    this point, you should see a few lines during early boot process if you
>    type "dmesg | grep -i xenomai".
> 
>    6. Finally, build the user-space binaries of xenomai, and deploy them on
>    your target.
> 
> Maybe someone can correct me if I am wrong, but I believe the
> "/proc/xenomai/version" pseudo-file is provided by the kernel, not by the
> user-space binaries. So, if it is missing on your board, it means something
> went wrong somewhere between steps 1 and 5.

The file is provided by the procfs pseudo-filesystem. If the /proc
directory is empty, chances are the /proc filesystem is not even mounted.

-- 
					    Gilles.
https://click-hack.org

[Xenomai] (no subject)

[Helder Daniel]

Hi,

I am trying to compile a kernel module that sets up a XDDP socket (code
snippet below).
But rtdm_bind() returns ENOSYS.
This means that I can not use XDDP sockets in kernel?

================================================
s = rtdm_socket(AF_RTIPC, SOCK_DGRAM, IPCPROTO_XDDP);
memset(&saddr, 0, sizeof(saddr));
saddr.sipc_family = AF_RTIPC;
saddr.sipc_port = XDDP_PORT;
ret = rtdm_bind(s, (struct sockaddr *)&saddr, sizeof(saddr));
if (ret) rtdm_printk("senderK: bind error: %d\n", ret);

================================================

[Xenomai] (no subject)

[alex.martin92]

Hi! This is for you  http://shinryu1226.web.fc2.com/-redirect?tifunyd72086148

[Xenomai] (no subject)

[Franz Engel]

Franz Engel wrote: 
> Philippe wrote
>> Philippe wrote: 
>>>> Franz Engel wrote: 
>>>> Hi, 
>>>> 
>>>> I get this error when I run a programm: 
>>>> __xn_sys_current_info failed: Operation not permitted 
>>>> 
>>>> I know that the error comes from the assert_nrt_inner(void) 
>>>> function inside the assert_context.c file. But I have no idea what 
>>>> is the reason. The Operation not permitted is the return value from 
>>>> XENOMAI_SYSCALL1(__xn_sys_current_info, &info);. But I found no 
>>>> documentation about this function. 
>>>>
>>>This is reminiscent of a symptom observed for a bug fixed in the 
>>>     -forge tree, a while ago: 
>>>http://git.xenomai.org/?p=xenomai-forge.git;a=commit;h=014898add6a697e1a0d69f9e20b910ade74f1940 
>>> 
>>>Do you happen to call fork() in your  application? 
>> 
>> Yes, I do. What I can do to solve the problem. Should I try to modify 
>> the xenomai files as discrept in the git-link? 
>> 
>>>     I'm unsure, although this would be possible to backport portions of the 
>>>     logic, the implementation has now diverged significantly between the 
>>>     2.x and 3.x code bases. 
>>\r>
>>>     Could you try the patch below? It's untested, but should work around 
>>>     the 
>>>     root issue in your case: 
>>> 
>>>     diff --git a/include/nucleus/compiler.h b/include/nucleus/compiler.h 
>>>     index 30f32c7..da4ea03 100644 
>>>     --- a/include/nucleus/compiler.h 
>>>     +++ b/include/nucleus/compiler.h 
>>>     @@ -37,9 +37,11 @@ 
>>> 
>>>        #ifdef __IN_XENO__ 
>>>        #if __GNUC__ == 4 && __GNUC_MINOR__ == 6 
>>>     -#define __constructor__ __attribute__((constructor, noclone)) 
>>>     +#define __constructor__ __attribute__((constructor(200), noclone)) 
>>>     +#define __late_constructor__ __attribute__((constructor, noclone)) 
>>>        #else /* Gcc not 4.6 */ 
>>>     -#define __constructor__ __attribute__((constructor)) 
>>>     +#define __constructor__ __attribute__((constructor(200))) 
>>>     +#define __late_constructor__ __attribute__((constructor)) 
>>>        #endif /* Gcc not 4.6 */ 
>>>        #endif /* In xenomai */ 
>>> 
>>>     diff --git a/src/skins/common/rt_print.c b/src/skins/common/rt_print.c 
>>>     index dfa8b33..e056cd6 100644 
>>>     --- a/src/skins/common/rt_print.c 
>>>     +++ b/src/skins/common/rt_print.c 
>>>     @@ -738,7 +738,7 @@ static void forked_child_init(void) 
>>>                spawn_printer_thread(); 
>>>     } 
>>> 
>>>     -static __constructor__ void __rt_print_init(void) 
>>>     +static __late_constructor__ void __rt_print_init(void) 
>>>        { 
>>>            const char *value_str; 
>>>            unsigned long long period; 
>>> 
>>>     -- 
>>>     Philippe. 
>> 
>>     I tried the patch. But I think it is not the correct version of 
>>     xenomai. In my compiler.h there is no line "#define __constructor__ 
>>     __attribute__((constructor, noclone))". I use Xenomai 2.6.2.1. 
>> 
 
>Simply ignore the noclone spec when applying the patch manually. You should end up with the >normal/high priority ctor at priority 200, the late one with an implicit, unspecified low priority. 
 
I'm not sure if I understand you correct. I change the function in rt_print.h (line 706) from "static __attribute__((constructor)) void __rt_print_init(void)" to "static __late_constructor__ void __rt_print_init(void)"
and I insert the following lines into the compiler.h (absolutly new lines):
#ifdef __IN_XENO__
  #if __GNUC__ == 4 && __GNUC_MINOR__ == 6
     #define __constructor__ __attribute__((constructor(200), noclone))
     #define __late_constructor__ __attribute__((constructor, noclone))
  #else /* Gcc not 4.6 */
     #define __constructor__ __attribute__((constructor(200)))
     #define __late_constructor__ __attribute__((constructor))
  #endif /* Gcc not 4.6 */
#endif /* In xenomai */

Is it correct? I have still the same failure.

regards,
      Franz

[Xenomai] (no subject)

[Mohammadreza Babaee]

Dear Xenomai,


I have applied the xenomai to kernel of Freescale (Version 3.0.15) but in
compiling got this error

arch/arm/mach-mx6/clock.c: In function '_clk_gpt_get_rate':
arch/arm/mach-mx6/clock.c:1857:2: error: implicit declaration of function
'mx6_timer_rate' [-Werror=implicit-function-declaration]


Does anyboday have idea what is the problem

Best

Re: [Xenomai] (no subject)

[Gilles Chanteperdrix]

On 03/27/2013 05:23 PM, Mohammadreza Babaee wrote:

> Dear Xenomai,
> 
> 
> I have applied the xenomai to kernel of Freescale (Version 3.0.15) but in
> compiling got this error
> 
> arch/arm/mach-mx6/clock.c: In function '_clk_gpt_get_rate':
> arch/arm/mach-mx6/clock.c:1857:2: error: implicit declaration of function
> 'mx6_timer_rate' [-Werror=implicit-function-declaration]


Hi,

Please do not send mails without subject.

You probably applied the patch to the wrong kernel version. See
ksrc/arch/arm/patches/README in Xenomai kernel sources for the exact git
commit to which you should apply the patch.

Alternatively, you can use the ipipe-3.0-imx6q branch in ipipe-gch git tree:
http://git.xenomai.org/?p=ipipe-gch.git;a=shortlog;h=refs/heads/ipipe-3.0-imx6q

Regards.

-- 
                                                                Gilles.

[Xenomai] (no subject)

[mfornero]

>> Is there a new ADEOS patch for ARM in the works ? I am interested to know
>> what kernel version is targeted if that decision has been made.

>3.8. It currently works on at91s, but not yet on omap. We will probably
>need to run tests on the imxs, as a lot of things have changed between
>3.5 and 3.8.

Hi Gilles,

Is there a public git tree with this work-in-progress? I couldn't pinpoint a 
specific one on git.xenomai.org or git.denx.de that was ARM/3.8 based

The Xilinx -next tree for Zynq looks like it's based on 3.8, so a 3.8 ipipe would
likely be much easier for me than attempting to back port all of the important patches.

On a related note, is there something I can do to help prevent the Zynq ipipe port from
bit-rotting? Even in 3.8, mainline is still missing a lot of the necessary code for Zynq,
so I assume I'd need a pre- and post- patch. Could you elaborate on what these would entail?

Best Regards,

Matt

Re: [Xenomai] (no subject)

[Gilles Chanteperdrix]

On 03/23/2013 05:06 PM, mfornero@aanddtech.com wrote:

>>> Is there a new ADEOS patch for ARM in the works ? I am interested to know
>>> what kernel version is targeted if that decision has been made.
> 
>> 3.8. It currently works on at91s, but not yet on omap. We will probably
>> need to run tests on the imxs, as a lot of things have changed between
>> 3.5 and 3.8.
> 
> Hi Gilles,


Hi,

your mail agent is not correctly configured, it sent the mail with an
empty suject, and without the "In-Reply-To, or References" headers set.
Please fix this. Your lines are also too long.

> 
> Is there a public git tree with this work-in-progress? I couldn't pinpoint a 
> specific one on git.xenomai.org or git.denx.de that was ARM/3.8 based


It is ipipe-gch.git, but the work in progress is not currently pushed
there, because I need to be able to rebase.

> 
> The Xilinx -next tree for Zynq looks like it's based on 3.8, so a 3.8 ipipe would
> likely be much easier for me than attempting to back port all of the important patches.
> 
> On a related note, is there something I can do to help prevent the Zynq ipipe port from
> bit-rotting? Even in 3.8, mainline is still missing a lot of the necessary code for Zynq,
> so I assume I'd need a pre- and post- patch. Could you elaborate on what these would entail?


The pre- and post- patches allow a SOC-specific port on a vendor branch
to only contain SOC-specific changes, and not the core of the I-pipe
changes, allowing to update the I-pipe patch without updating the
SOC-specifc port. The pre and post patches are artificial, generated
with differences between specific trees, they do not need to reflect the
way you maintaint the SOC-specific I-pipe for the vendor branch.

Regards.

-- 
                                                                Gilles.

Re: [Xenomai] (no subject)

[Gilles Chanteperdrix]

On 03/23/2013 05:06 PM, mfornero@aanddtech.com wrote:

>>> Is there a new ADEOS patch for ARM in the works ? I am interested to know
>>> what kernel version is targeted if that decision has been made.
> 
>> 3.8. It currently works on at91s, but not yet on omap. We will probably
>> need to run tests on the imxs, as a lot of things have changed between
>> 3.5 and 3.8.
> 
> Hi Gilles,
> 
> Is there a public git tree with this work-in-progress? I couldn't pinpoint a 
> specific one on git.xenomai.org or git.denx.de that was ARM/3.8 based
> 
> The Xilinx -next tree for Zynq looks like it's based on 3.8, so a 3.8 ipipe would
> likely be much easier for me than attempting to back port all of the important patches.
> 
> On a related note, is there something I can do to help prevent the Zynq ipipe port from
> bit-rotting? Even in 3.8, mainline is still missing a lot of the necessary code for Zynq,
> so I assume I'd need a pre- and post- patch. Could you elaborate on what these would entail?


Hi,

You can have a look at the "next" branch in the ipipe-gch git
repository, it is work in progress, but currently boot on at91, omap3
and omap4 (cortex A9 SMP, like Zynq). The solution currently used to
allow the I-pipe working with IRQDOMAINS is not very satisfactory and
should be improved in next versions.

Regards.

-- 
                                                                Gilles.

[Xenomai] (no subject)

[RAGHAVENDRA GANIGA]

I am starting my project on pandaboard(OMAP4430).For that I want to know
the  stable supported version of linux,xenomai & adeos patch for that
board.
Thank you.

[Xenomai] (no subject)

[Shamju Joseph]

Hi

I’m facing some problem with Xenomai. I have to run kernel patched with
xenomai on a multi core system. (Panasonic laptop with core duo and dell
laptop with core i5 processor) The kernel configuration says “Warning you
enabled APM, CPU frequency scaling or ACPI processor. These options are
known to cause trouble with xenomai”. But if I disable ACPI and build
kernel patched with xenomai, I get only one core after booting. (Even if
SMP is selected & max no of CPUs is set ). So I enabled ACPI and built
kernel with xenomai patch. I could boot the kernel and got multiple core
listed in /proc/cpuinfo. But the issue is that when I call xenomai API task
spawn on the second core, program hangs for long time. Also observed lot of
timing variations in the latency test.

I tried with Fedora 14 and RHEL 6 distributions. I used kernel 2.6.37 and
xenomai 2.5.6 versions. The following are the output I got from system.

[gddr@M4500 ~]$ dmesg | grep Xenomai

[    1.665262] I-pipe: Domain Xenomai registered.

[    1.665266] Xenomai: hal/i386 started.

[    1.665285] Xenomai: scheduling class idle registered.

[    1.665287] Xenomai: scheduling class rt registered.

[    1.665719] Xenomai: real-time nucleus v2.5.6 (Wormhole Wizards) loaded.

[    1.665798] Xenomai: SMI-enabled chipset found

[    1.665808] Xenomai: SMI workaround enabled

[    1.665816] Xenomai: starting native API services.

[    1.665817] Xenomai: starting POSIX services.

[    1.665835] Xenomai: starting RTDM services.

[gddr@M4500 ~]$

[gddr@M4500 ~]$ dmesg | grep I-pipe

[    0.000000] I-pipe 2.9-00: pipeline enabled.

[    1.665262] I-pipe: Domain Xenomai registered.

[gddr@M4500 ~]$

I’ve the following doubts.

1)      How to get xenomai working with multi core processor system?

2)      There are many services like cpuspeed, irqbalance, crond, sendmail,
acpid, pcscd, iscsi etc running in the background by default. Are these
causing some problem with xenomai? What are the essential services required
and what are to be disabled?

3)      Is there any standard or HOWTO document available which explains
the detailed installation steps (kernel configurations to set/clear & Linux
services to enable/disable) for xenomai?

Please help me.
-Shamju Joseph

Re: [Xenomai] (no subject)

[Gilles Chanteperdrix]

On 12/15/2012 09:49 AM, Shamju Joseph wrote:

> The kernel configuration says “Warning you
> enabled APM, CPU frequency scaling or ACPI processor. These options are
> known to cause trouble with xenomai”. But if I disable ACPI


See: 
http://www.xenomai.org/index.php/Configuring_x86_kernels#Power_management

-- 
                                                                Gilles.