[Xenomai-core] Xenomai port to MIPS
Hi All, After a good study with help of mailing list, we fix on porting Xenomai to our ustom board running with Mips4k . what I understand is we have Adeos with Xenomai, and realtime capability of Xenomai. our ultimate goal is realtime. To Begin with port of Xenomai I would like to know , in case is there a porting doc or some pointer which help to understand Xenomai better and quick, to go ahead. Please comment on this. Thanks In Advance Neelu __ Yahoo! India Answers: Share what you know. Learn something new http://in.answers.yahoo.com/ ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Xenomai port to MIPS
somshekar kadam wrote: Hi All, After a good study with help of mailing list, we fix on porting Xenomai to our ustom board running with Mips4k . what I understand is we have Adeos with Xenomai, and realtime capability of Xenomai. our ultimate goal is realtime. To Begin with port of Xenomai I would like to know , in case is there a porting doc or some pointer which help to understand Xenomai better and quick, to go ahead. Please comment on this. Thanks In Advance Neelu __ Yahoo! India Answers: Share what you know. Learn something new http://in.answers.yahoo.com/ ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core I am also very intrerested in this kind of porting guidance, because I have to evaluate the difficulties in porting Xenomai (and Adeos) into Coldfire v4 (m68k) architecture. Thanks Miguel Ángel - PLEASE NOTE --- This message, along with any attachments, may be confidential or legally privileged. It is intended only for the named person(s), who is/are the only authorized recipients. If this message has reached you in error, kindly destroy it without review and notify the sender immediately. Thank you for your help. µSysCom uses virus scanning software but excludes any liability for viruses contained in any attachment. ROGAMOS LEA ESTE TEXTO --- Este mensaje y sus anexos pueden contener información confidencial y/o con derecho legal. Está dirigido únicamente a la/s persona/s o entidad/es reseñadas como único destinatario autorizado. Si este mensaje le hubiera llegado por error, por favor elimínelo sin revisarlo ni reenviarlo y notifíquelo inmediatamente al remitente. Gracias por su colaboración. µSysCom utiliza software antivirus, pero no se hace responsable de los virus contenidos en los ficheros anexos. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Xenomai port to MIPS
somshekar kadam wrote: Hi All, After a good study with help of mailing list, we fix on porting Xenomai to our ustom board running with Mips4k . Nice to hear. :) what I understand is we have Adeos with Xenomai, and realtime capability of Xenomai. Yep. our ultimate goal is realtime. To Begin with port of Xenomai I would like to know , in case is there a porting doc or some pointer which help to understand Xenomai better and quick, to go ahead. Please comment on this. Your first step still remains the fairly independent port of Adeos/Ipipe over MIPS. Philippe already pointed out the available resources. Start over a recent vanilla kernel (or do you need special patches for your targets?), make Linux boot with Ipipe enabled, then stress the event pipeline with a simple Ipipe test module. Once this works you can proceed to Xenomai, porting over what's under ksrc/arch/arch and include/asm-arch. Not all internal functions may be documented. Try to grab their meaning from other archs and/or their usage - or ask on this list. Another hint: post your patches early even if they do not work yet. We may have a look and comment on style and functionality. This will make it easier to finally merge them (which should be your goal to ease long-term maintenance). And it may attract early adopters that can provide further feedback and test results. Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Xenomai port to MIPS
Hi Jan, To begin with porting I need some help you people, I dont see an announcement of Xenomai start, who are the Authors and maintainers of this I know were very well its you and Philipe Gerum and others also whom i dont know. As I need to put all this in a document , can help me on this. Thanks In Advance Neelu my nick name --- Jan Kiszka [EMAIL PROTECTED] wrote: somshekar kadam wrote: Hi All, After a good study with help of mailing list, we fix on porting Xenomai to our ustom board running with Mips4k . Nice to hear. :) what I understand is we have Adeos with Xenomai, and realtime capability of Xenomai. Yep. our ultimate goal is realtime. To Begin with port of Xenomai I would like to know , in case is there a porting doc or some pointer which help to understand Xenomai better and quick, to go ahead. Please comment on this. Your first step still remains the fairly independent port of Adeos/Ipipe over MIPS. Philippe already pointed out the available resources. Start over a recent vanilla kernel (or do you need special patches for your targets?), make Linux boot with Ipipe enabled, then stress the event pipeline with a simple Ipipe test module. Once this works you can proceed to Xenomai, porting over what's under ksrc/arch/arch and include/asm-arch. Not all internal functions may be documented. Try to grab their meaning from other archs and/or their usage - or ask on this list. Another hint: post your patches early even if they do not work yet. We may have a look and comment on style and functionality. This will make it easier to finally merge them (which should be your goal to ease long-term maintenance). And it may attract early adopters that can provide further feedback and test results. Jan __ Yahoo! India Answers: Share what you know. Learn something new http://in.answers.yahoo.com/ ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Xenomai port to MIPS
Miguel Angel Alvarez wrote: I am also very intrerested in this kind of porting guidance, because I have to evaluate the difficulties in porting Xenomai (and Adeos) into Coldfire v4 (m68k) architecture. See this posting for the Adeos part: https://mail.gna.org/public/adeos-main/2006-09/msg1.html Regarding the porting effort of Xenomai: I would recommend to browse through existing architectures, e.g. Blackfin, in order to asses the amount and complexity of services you have to deal with. Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Xenomai port to MIPS
somshekar kadam wrote: Hi Jan, To begin with porting I need some help you people, I dont see an announcement of Xenomai start, who are the Authors and maintainers of this I know were very well its you and Philipe Gerum and others also whom i dont know. As I need to put all this in a document , can help me on this. Mmh, I'm not yet sure I understood completely what you are looking for, but if its the start of Xenomai 2 + its history, this may help: https://mail.gna.org/public/rtai-dev/2005-10/msg2.html More contributors can be found in the CREDITS file, including those who work on important parts that don't show up in the ChangeLog. A comprehensive roadmap document is in the making, but we cannot provide a concrete release date yet. Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Move rtdm_irq_enable close to rtdm_irq_request
Hi Wolfgang, in the process of preparing to merge rtdm_irq_enable into rtdm_irq_request I would like to check if the attached patch is ok, thus we could finally drop rtdm_irq_enable once the API is refactored. Please check carefully when the first IRQs may happen and what the handler expects to be initialised! SJA1000 /should/ be ok as it works with shared IRQs, but MSCAN does not (why, BTW?) and /may/ stumble. Jan Index: ksrc/drivers/can/mscan/rtcan_mscan.c === --- ksrc/drivers/can/mscan/rtcan_mscan.c(revision 1559) +++ ksrc/drivers/can/mscan/rtcan_mscan.c(working copy) @@ -801,7 +801,8 @@ int __init rtcan_mscan_init_one(int idx) printk(ERROR! rtdm_irq_request for IRQ %d failed\n, irq); goto out_dev_free; } - +rtdm_irq_enable(dev-irq_handle); + mscan_chip_config(regs); @@ -814,8 +815,6 @@ int __init rtcan_mscan_init_one(int idx) rtcan_mscan_create_proc(dev); -rtdm_irq_enable(dev-irq_handle); - /* Remember initialized devices */ rtcan_mscan_devs[idx] = dev; Index: ksrc/drivers/can/sja1000/rtcan_sja1000.c === --- ksrc/drivers/can/sja1000/rtcan_sja1000.c(revision 1559) +++ ksrc/drivers/can/sja1000/rtcan_sja1000.c(working copy) @@ -747,6 +747,7 @@ int rtcan_sja1000_register(struct rtcan_ printk(ERROR! IRQ %d busy or invalid (code=%d)!\n, chip-irq_num, ret); return ret; } +rtdm_irq_enable(dev-irq_handle); sja1000_chip_config(dev); @@ -759,8 +760,6 @@ int rtcan_sja1000_register(struct rtcan_ rtcan_sja_create_proc(dev); -rtdm_irq_enable(dev-irq_handle); - return 0; out_irq_free: signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] RTAI Vs Xenomai performance
somshekar kadam wrote: HI Jan, I am runnng the testsuite given by RTAI and Xenomai, I need to this figures to compare on performance for the doc to port XENOMAI on MIPS. I see RTAI gives results in nanoseconds and XENOMAI in microsecond, so i should say latency with Xenomai is 3000 micrsecond where as RTAI its 3000 Nanosecond , correct me if I am wrong. I have attached both testsuite reults As indicated by the overruns count, you have a hardware problem, most likely an issue with SMIs, or power management. Please read the TROUBLESHOOTING file. -- Gilles Chanteperdrix. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Re: RTAI Vs Xenomai performance
Hi Neelu, please start a new thread when switching the topic, don't reply to existing ones (CC'ing people who may not want this). somshekar kadam wrote: HI Jan, I am runnng the testsuite given by RTAI and Xenomai, I need to this figures to compare on performance for the doc to port XENOMAI on MIPS. I see RTAI gives results in nanoseconds and XENOMAI in microsecond, so i should say latency with Xenomai is 3000 micrsecond where as RTAI its 3000 Nanosecond , correct me if I am wrong. RTAI is in nanoseconds as Xenomai used to be in early days, but its results are as broken as Xenomai's (watch out for the maximum!). I have attached both testsuite reults You likely have a SMI problem, see TROUBLESHOOTING for details. This makes me wonder if some simple test (dmesg | grep CONFIG_XENO_HW_SMI_WORKAROUND) in latency or at least in xeno_test to detect this may make this FAQ less frequent... :) Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] RTAI Vs Xenomai performance
HI Jan, I am runnng the testsuite given by RTAI and Xenomai, I need to this figures to compare on performance for the doc to port XENOMAI on MIPS. I see RTAI gives results in nanoseconds and XENOMAI in microsecond, so i should say latency with Xenomai is 3000 micrsecond where as RTAI its 3000 Nanosecond , correct me if I am wrong. I have attached both testsuite reults Thanks In Advance Neelu --- Jan Kiszka [EMAIL PROTECTED] wrote: Miguel Angel Alvarez wrote: I am also very intrerested in this kind of porting guidance, because I have to evaluate the difficulties in porting Xenomai (and Adeos) into Coldfire v4 (m68k) architecture. See this posting for the Adeos part: https://mail.gna.org/public/adeos-main/2006-09/msg1.html Regarding the porting effort of Xenomai: I would recommend to browse through existing architectures, e.g. Blackfin, in order to asses the amount and complexity of services you have to deal with. Jan __ Yahoo! India Answers: Share what you know. Learn something new http://in.answers.yahoo.com/== Sampling period: 100 us == Test mode: periodic user-mode task == All results in microseconds warming up... RTT| 00:00:01 (periodic user-mode task, 100 us period) RTH|-lat min|-lat avg|-lat max|-overrun|lat best|---lat worst RTD| 0.363| 1.307| 6.443| 0| 0.363| 6.443 RTD| 0.259| 68.339| 594.219| 5| 0.259| 594.219 RTD| 500.179| 18.290| 506.059| 5| 0.259| 594.219 RTD| 500.254| 18.285| 505.818| 5| 0.259| 594.219 RTD| 500.265| 18.323| 506.288| 5| 0.259| 594.219 RTD| 500.212| 18.288| 508.575| 5| 0.259| 594.219 RTD| 500.354| -2.511|1129.323| 11| 0.259|1129.323 RTD|1100.297| -25.688|1108.217| 11| 0.259|1129.323 RTD|1100.244| -25.686|1108.423| 11| 0.259|1129.323 RTD|1100.177| -25.686|1108.608| 11| 0.259|1129.323 RTD|1100.172| 16.570|1675.939| 16| 0.259|1675.939 RTD|1600.103| -8.670|1608.491| 16| 0.259|1675.939 RTD|1600.266| -8.666|1608.856| 16| 0.259|1675.939 RTD|1600.227| -8.665|1608.532| 16| 0.259|1675.939 RTD|1600.025| -8.662|1608.813| 16| 0.259|1675.939 RTD|1600.415| 29.702|2202.194| 21| 0.259|2202.194 RTD|2100.416| 8.355|2108.844| 21| 0.259|2202.194 RTD|2100.301| 8.355|2108.579| 21| 0.259|2202.194 RTD|2100.323| 8.350|2108.491| 21| 0.259|2202.194 RTD|2100.137| 8.352|2108.733| 21| 0.259|2202.194 RTD|2100.402| 42.772|2661.862| 26| 0.259|2661.862 RTT| 00:00:22 (periodic user-mode task, 100 us period) RTH|-lat min|-lat avg|-lat max|-overrun|lat best|---lat worst RTD|2600.325| 25.370|2608.703| 26| 0.259|2661.862 RTD|2600.041| 25.371|2608.807| 26| 0.259|2661.862 RTD|2600.179| 25.368|2608.871| 26| 0.259|2661.862 RTD|2600.228| 38.876|3201.108| 31| 0.259|3201.108 RTD|3100.178| 42.382|3109.105| 31| 0.259|3201.108 RTD|3098.880| 42.348|3108.497| 31| 0.259|3201.108 RTD|3098.891| 42.361|3109.042| 31| 0.259|3201.108 RTD|3100.342| 42.399|3108.477| 31| 0.259|3201.108 RTD|3100.263| 52.008|3648.872| 36| 0.259|3648.872 RTD|3600.352| 59.412|3608.707| 36| 0.259|3648.872 RTD|3600.307| 59.408|3608.992| 36| 0.259|3648.872 RTD|3600.490| 59.400|3608.473| 36| 0.259|3648.872 RTD|3600.300| 59.404|3609.087| 36| 0.259|3648.872 RTD|3600.145| 65.078|4192.166| 41| 0.259|4192.166 RTD|3748.422| 76.426|4108.637| 41| 0.259|4192.166 RTD|3748.422| 76.424|4108.577| 41| 0.259|4192.166 RTD|3748.422| 76.427|4108.534| 41| 0.259|4192.166 RTD|3748.422| 76.423|4108.954| 41| 0.259|4192.166 RTD|3748.422| 14.152|4725.161| 47| 0.259|4725.161 RTD|3748.422| 32.450|4708.704| 47| 0.259|4725.161 RTD|3748.422| 32.474|4708.777| 47| 0.259|4725.161 RTT| 00:00:43 (periodic user-mode task, 100 us period) RTH|-lat min|-lat avg|-lat max|-overrun|lat best|---lat worst RTD|3748.422| 32.828|4709.061| 47|
[Xenomai-core] Re: Move rtdm_irq_enable close to rtdm_irq_request
Jan Kiszka wrote: Hi Wolfgang, in the process of preparing to merge rtdm_irq_enable into rtdm_irq_request I would like to check if the attached patch is ok, thus we could finally drop rtdm_irq_enable once the API is refactored. Please check carefully when the first IRQs may happen and what the handler expects to be initialised! SJA1000 /should/ be ok as it works with shared IRQs, but MSCAN does not (why, BTW?) and /may/ stumble. OK. Why should I use shared interrupts if there is no need? Most embedded PowerPC systems have a dedicated interrupt source. Wolfgang. Jan Index: ksrc/drivers/can/mscan/rtcan_mscan.c === --- ksrc/drivers/can/mscan/rtcan_mscan.c(revision 1559) +++ ksrc/drivers/can/mscan/rtcan_mscan.c(working copy) @@ -801,7 +801,8 @@ int __init rtcan_mscan_init_one(int idx) printk(ERROR! rtdm_irq_request for IRQ %d failed\n, irq); goto out_dev_free; } - +rtdm_irq_enable(dev-irq_handle); + mscan_chip_config(regs); @@ -814,8 +815,6 @@ int __init rtcan_mscan_init_one(int idx) rtcan_mscan_create_proc(dev); -rtdm_irq_enable(dev-irq_handle); - /* Remember initialized devices */ rtcan_mscan_devs[idx] = dev; Index: ksrc/drivers/can/sja1000/rtcan_sja1000.c === --- ksrc/drivers/can/sja1000/rtcan_sja1000.c(revision 1559) +++ ksrc/drivers/can/sja1000/rtcan_sja1000.c(working copy) @@ -747,6 +747,7 @@ int rtcan_sja1000_register(struct rtcan_ printk(ERROR! IRQ %d busy or invalid (code=%d)!\n, chip-irq_num, ret); return ret; } +rtdm_irq_enable(dev-irq_handle); sja1000_chip_config(dev); @@ -759,8 +760,6 @@ int rtcan_sja1000_register(struct rtcan_ rtcan_sja_create_proc(dev); -rtdm_irq_enable(dev-irq_handle); - return 0; out_irq_free: ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Re: Move rtdm_irq_enable close to rtdm_irq_request
Wolfgang Grandegger wrote: Jan Kiszka wrote: Hi Wolfgang, in the process of preparing to merge rtdm_irq_enable into rtdm_irq_request I would like to check if the attached patch is ok, thus we could finally drop rtdm_irq_enable once the API is refactored. Please check carefully when the first IRQs may happen and what the handler expects to be initialised! SJA1000 /should/ be ok as it works with shared IRQs, but MSCAN does not (why, BTW?) and /may/ stumble. OK. Why should I use shared interrupts if there is no need? Most embedded PowerPC systems have a dedicated interrupt source. Of course, /me forgot once again that not all the world is designed like crappy x86. :) At this chance I looked over the irq_flag mechanism of the CAN stack and found a minor cleanup: this #ifdef [1] is not required. If there is no sharing support, the subscriber will simply be redirected to the non-shared handler. @Dmitry: What happens under CONFIG_XENO_OPT_SHIRQ_LEVEL !CONFIG_XENO_OPT_SHIRQ_EDGE when someone comes along with XN_ISR_SHARED|XN_ISR_EDGE? Looks like the level-triggered shared handler gets installed. Should we catch this? At Kconfig or at nucleus level? Jan [1]http://www.rts.uni-hannover.de/xenomai/lxr/source/ksrc/drivers/can/sja1000/rtcan_peak_pci.c?v=SVN-trunk#L233 signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
