Re: [Xenomai-core] Problems generating vxworks/koan in two step: cc and link
Niklaus Giger wrote: > ld -o koan -L/usr/xenomai/lib -luvm -lnucleus -lpthread -lvxworks -lnative > -e __xeno_skin_init /home/hcu/project/bb/3_1_x/work/xeno/koan.o > Now I get the following error output > ld: warning: cannot find entry symbol __xeno_skin_init; defaulting to > 12a0 > /home/hcu/project/bb/3_1_x/work/xeno/koan.o: In function `TaskTest':koan.c: > (.text+0xbc): undefined reference to `semTake' > /home/hcu/project/bb/3_1_x/work/xeno/koan.o: In function `CreateTask':koan.c: > (.text+0x124): undefined reference to `taskSpawn' > /home/hcu/project/bb/3_1_x/work/xeno/koan.o: In function `usrClock':koan.c: > (.text+0x1c8): undefined reference to `semGive' > :koan.c:(.text+0x1f0): undefined reference to `tickAnnounce' > /home/hcu/project/bb/3_1_x/work/xeno/koan.o: In function > `koan_sysClkInit':koan.c:(.text+0x224): undefined reference to `semBCreate' > :koan.c:(.text+0x23c): undefined reference to `sysClkConnect' > :koan.c:(.text+0x240): undefined reference to `sysClkEnable' > /home/hcu/project/bb/3_1_x/work/xeno/koan.o: In function > `__xeno_user_exit':koan.c:(.text+0x2c0): undefined reference to `taskDelete' > > What is wrong with my split? What happens if you try : cc -u __xeno_skin_init -o koan -L/usr/xenomai/lib -luvm -lnucleus -lpthread -lvxworks -lnative /home/hcu/project/bb/3_1_x/work/xeno/koan.o -u seems to be a link-time option. -- Gilles Chanteperdrix.
[Xenomai-core] Problems generating vxworks/koan in two step: cc and link
Hi I am trying to bring my build infrastructure up to Xenomai 2.1 and got the following problem: I have no problems to generate koan using the following command: cc -o koan2 /home/hcu/kernel/tst_xeno_ppc/koan.c -I. \ -I/usr/xenomai/include -O2 -D_GNU_SOURCE -D_REENTRANT -D__XENO__ -Wall \ -pipe -D__XENO_UVM__ -u__xeno_skin_init -L/usr/xenomai/lib -luvm -lnucleus \ -lpthread -lvxworks -lnative No in order to be able to compile and link bigger applications my first try was to compile koan first and then to link. However running the following two commands c -c -I. -I/usr/xenomai/include -O2 -D_GNU_SOURCE -D_REENTRANT -D__XENO__ -Wall -pipe -D__XENO_UVM__ -u__xeno_skin_init -I. /home/hcu/project/bb/3_1_x/work/xeno/koan.c -o /home/hcu/project/bb/3_1_x/work/xeno/koan.o ld -o koan -L/usr/xenomai/lib -luvm -lnucleus -lpthread -lvxworks -lnative -e __xeno_skin_init /home/hcu/project/bb/3_1_x/work/xeno/koan.o Now I get the following error output ld: warning: cannot find entry symbol __xeno_skin_init; defaulting to 12a0 /home/hcu/project/bb/3_1_x/work/xeno/koan.o: In function `TaskTest':koan.c: (.text+0xbc): undefined reference to `semTake' /home/hcu/project/bb/3_1_x/work/xeno/koan.o: In function `CreateTask':koan.c: (.text+0x124): undefined reference to `taskSpawn' /home/hcu/project/bb/3_1_x/work/xeno/koan.o: In function `usrClock':koan.c: (.text+0x1c8): undefined reference to `semGive' :koan.c:(.text+0x1f0): undefined reference to `tickAnnounce' /home/hcu/project/bb/3_1_x/work/xeno/koan.o: In function `koan_sysClkInit':koan.c:(.text+0x224): undefined reference to `semBCreate' :koan.c:(.text+0x23c): undefined reference to `sysClkConnect' :koan.c:(.text+0x240): undefined reference to `sysClkEnable' /home/hcu/project/bb/3_1_x/work/xeno/koan.o: In function `__xeno_user_exit':koan.c:(.text+0x2c0): undefined reference to `taskDelete' What is wrong with my split? -- Niklaus Giger
Re: [Xenomai-core] Initialization of a nucleus pod
Thank you for your response So rootcb isn't the "scheduler task". I was thinking it was this task which was determining what thread to run, depending of its parameters (priority, periodicity, scheduling mode). I go back to the code to understand how it work ... Germain > > xnthread_init does part of the initialization. The low level part of > rootcb (its xnarchtcb_t member) is initialized twice, first by the call > to xnarch_init_tcb in xnthread_init, and then overriden by > xnarch_init_root_tcb in xnpod_init. > > For any other thread than root, the thread would be given a stack and > entry point by the call to xnarch_init_thread in xnpod_start_thread. But > the root thread is Xenomai idle task, a placeholder for whatever task > Linux is currenty running. At the time where xnpod_init is called, the > root thread is the current context, so already has a stack and is > already running. > > -- > > > Gilles Chanteperdrix. >
Re: [Xenomai-core] Missing IRQ end function on PowerPC
Gilles Chanteperdrix wrote: Wolfgang Grandegger wrote: > Therefore we need a dedicated function to re-enable interrupts in the > ISR. We could name it *_end_irq, but maybe *_enable_isr_irq is more > obvious. On non-PPC archs it would translate to *_irq_enable. I > realized, that *_irq_enable is used in various place/skins and therefore > I have not yet provided a patch. The function xnarch_irq_enable seems to be called in only two functions, xintr_enable and xnintr_irq_handler when the flag XN_ISR_ENABLE is set. But the user may want to re-enable the interrupt without using XN_ISR_ENABLE as well. In any case, since I am not sure if this has to be done at the Adeos level or in Xenomai, we will wait for Philippe to come back and decide. In both, I guess. OK and thanks. Wolfgang.
Re: [Xenomai-core] Missing IRQ end function on PowerPC
Wolfgang Grandegger wrote: > Therefore we need a dedicated function to re-enable interrupts in the > ISR. We could name it *_end_irq, but maybe *_enable_isr_irq is more > obvious. On non-PPC archs it would translate to *_irq_enable. I > realized, that *_irq_enable is used in various place/skins and therefore > I have not yet provided a patch. The function xnarch_irq_enable seems to be called in only two functions, xintr_enable and xnintr_irq_handler when the flag XN_ISR_ENABLE is set. In any case, since I am not sure if this has to be done at the Adeos level or in Xenomai, we will wait for Philippe to come back and decide. -- Gilles Chanteperdrix.
Re: [Xenomai-core] Problems generating vxworks/koan in two step: cc and link
Niklaus Giger wrote: > ld -o koan -L/usr/xenomai/lib -luvm -lnucleus -lpthread -lvxworks -lnative > -e __xeno_skin_init /home/hcu/project/bb/3_1_x/work/xeno/koan.o > Now I get the following error output > ld: warning: cannot find entry symbol __xeno_skin_init; defaulting to > 12a0 > /home/hcu/project/bb/3_1_x/work/xeno/koan.o: In function `TaskTest':koan.c: > (.text+0xbc): undefined reference to `semTake' > /home/hcu/project/bb/3_1_x/work/xeno/koan.o: In function `CreateTask':koan.c: > (.text+0x124): undefined reference to `taskSpawn' > /home/hcu/project/bb/3_1_x/work/xeno/koan.o: In function `usrClock':koan.c: > (.text+0x1c8): undefined reference to `semGive' > :koan.c:(.text+0x1f0): undefined reference to `tickAnnounce' > /home/hcu/project/bb/3_1_x/work/xeno/koan.o: In function > `koan_sysClkInit':koan.c:(.text+0x224): undefined reference to `semBCreate' > :koan.c:(.text+0x23c): undefined reference to `sysClkConnect' > :koan.c:(.text+0x240): undefined reference to `sysClkEnable' > /home/hcu/project/bb/3_1_x/work/xeno/koan.o: In function > `__xeno_user_exit':koan.c:(.text+0x2c0): undefined reference to `taskDelete' > > What is wrong with my split? What happens if you try : cc -u __xeno_skin_init -o koan -L/usr/xenomai/lib -luvm -lnucleus -lpthread -lvxworks -lnative /home/hcu/project/bb/3_1_x/work/xeno/koan.o -u seems to be a link-time option. -- Gilles Chanteperdrix. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Missing IRQ end function on PowerPC
Gilles Chanteperdrix wrote:
Wolfgang Grandegger wrote:
> Hello,
>
> with RTnet over Xenomai and Linux 2.4 on PowerPC I realized that Xenomai
> does not distinguish between a normal IRQ enable and an IRQ unmask at
> the end of an ISR (to reenable the IRQ). In the latter case the IRQ
> should be enabled on PowerPC as shown:
>
> if (rthal_irq_descp(irq)->handler->end != NULL)
> rthal_irq_descp(irq)->handler->end(irq);
> else
> rthal_irq_descp(irq)->handler->enable(irq);
>
> To handle this case properly, we need to different functions, I think.
I am not sure I understand what you mean. Would you want functions
rthal_end_irq and xnarch_end_irq added and that this xnarch_end_irq
would be called in xnintr_irq_handler when XN_ISR_ENABLE is set ?
Yes, that's what I have basically done to get the RTnet SCC enet driver
working on my MPC8xx module. In arch/ppc/kernel/irq.c you can see how
Linux re-enables interrupts at the end of it's ISR (see
http://cvs.gna.org/cvsweb/linux/v2.4/2.4.25-ppc/arch/ppc/kernel/irq.c?rev=1.1;cvsroot=adeos):
507: * The ->end() handler has to deal with interrupts which got
508: * disabled while the handler was running.
509: */
510: if (desc->handler) {
511: if (desc->handler->end)
512: desc->handler->end(irq);
513: else if (desc->handler->enable)
514: desc->handler->enable(irq);
In PPC Linux 2.6 things are a bit different. The "end" functions seems
to be mandatory now (I have to check more carefully).
Therefore we need a dedicated function to re-enable interrupts in the
ISR. We could name it *_end_irq, but maybe *_enable_isr_irq is more
obvious. On non-PPC archs it would translate to *_irq_enable. I
realized, that *_irq_enable is used in various place/skins and therefore
I have not yet provided a patch.
Wolfgang.
Re: [Xenomai-core] Initialization of a nucleus pod
Germain Olivier wrote: > Hello > > I am trying to understand how a pod is initialized. > > I think it start with xncore_attach() from core.c, then with xnpod_init from > pod.c > But here (in xnpod_init) there is something not clear about the root thread > creation. > > It use xnthread_init(&sched->rootcb, ...), but I don't see where > &sched->rootcb is initialized xnthread_init does part of the initialization. The low level part of rootcb (its xnarchtcb_t member) is initialized twice, first by the call to xnarch_init_tcb in xnthread_init, and then overriden by xnarch_init_root_tcb in xnpod_init. For any other thread than root, the thread would be given a stack and entry point by the call to xnarch_init_thread in xnpod_start_thread. But the root thread is Xenomai idle task, a placeholder for whatever task Linux is currenty running. At the time where xnpod_init is called, the root thread is the current context, so already has a stack and is already running. -- Gilles Chanteperdrix.
Re: [Xenomai-core] Missing IRQ end function on PowerPC
Wolfgang Grandegger wrote: > Hello, > > with RTnet over Xenomai and Linux 2.4 on PowerPC I realized that Xenomai > does not distinguish between a normal IRQ enable and an IRQ unmask at > the end of an ISR (to reenable the IRQ). In the latter case the IRQ > should be enabled on PowerPC as shown: > > if (rthal_irq_descp(irq)->handler->end != NULL) > rthal_irq_descp(irq)->handler->end(irq); > else > rthal_irq_descp(irq)->handler->enable(irq); > > To handle this case properly, we need to different functions, I think. I am not sure I understand what you mean. Would you want functions rthal_end_irq and xnarch_end_irq added and that this xnarch_end_irq would be called in xnintr_irq_handler when XN_ISR_ENABLE is set ? -- Gilles Chanteperdrix.
[Xenomai-core] Problems generating vxworks/koan in two step: cc and link
Hi I am trying to bring my build infrastructure up to Xenomai 2.1 and got the following problem: I have no problems to generate koan using the following command: cc -o koan2 /home/hcu/kernel/tst_xeno_ppc/koan.c -I. \ -I/usr/xenomai/include -O2 -D_GNU_SOURCE -D_REENTRANT -D__XENO__ -Wall \ -pipe -D__XENO_UVM__ -u__xeno_skin_init -L/usr/xenomai/lib -luvm -lnucleus \ -lpthread -lvxworks -lnative No in order to be able to compile and link bigger applications my first try was to compile koan first and then to link. However running the following two commands c -c -I. -I/usr/xenomai/include -O2 -D_GNU_SOURCE -D_REENTRANT -D__XENO__ -Wall -pipe -D__XENO_UVM__ -u__xeno_skin_init -I. /home/hcu/project/bb/3_1_x/work/xeno/koan.c -o /home/hcu/project/bb/3_1_x/work/xeno/koan.o ld -o koan -L/usr/xenomai/lib -luvm -lnucleus -lpthread -lvxworks -lnative -e __xeno_skin_init /home/hcu/project/bb/3_1_x/work/xeno/koan.o Now I get the following error output ld: warning: cannot find entry symbol __xeno_skin_init; defaulting to 12a0 /home/hcu/project/bb/3_1_x/work/xeno/koan.o: In function `TaskTest':koan.c: (.text+0xbc): undefined reference to `semTake' /home/hcu/project/bb/3_1_x/work/xeno/koan.o: In function `CreateTask':koan.c: (.text+0x124): undefined reference to `taskSpawn' /home/hcu/project/bb/3_1_x/work/xeno/koan.o: In function `usrClock':koan.c: (.text+0x1c8): undefined reference to `semGive' :koan.c:(.text+0x1f0): undefined reference to `tickAnnounce' /home/hcu/project/bb/3_1_x/work/xeno/koan.o: In function `koan_sysClkInit':koan.c:(.text+0x224): undefined reference to `semBCreate' :koan.c:(.text+0x23c): undefined reference to `sysClkConnect' :koan.c:(.text+0x240): undefined reference to `sysClkEnable' /home/hcu/project/bb/3_1_x/work/xeno/koan.o: In function `__xeno_user_exit':koan.c:(.text+0x2c0): undefined reference to `taskDelete' What is wrong with my split? -- Niklaus Giger ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] RTAI vs XENOMAI
Doyle, Alan \(Siemens\) wrote: > Hi, > > I'm looking into porting an embedded application using Accelerated > Technologies 'Nucleus' RTOS to a real time Linux variant. RTAI is the > preferred approach but on looking into available documentation I have > discovered Xenomai which seems to be designed to solve this sort of > problem. However as there is no existing emulator for Nucleus on Xenomai > I would have to write one so I'm unsure whether there would then be any > benefit. Could somebody advise me as to the pros and cons of porting to > RTAI or Xenomai. Using Xenomai would ease writing a skin for the nucleus RTOS. Philippe once wrote a mail on how to write a new skin, which you will find on rtai.dk: http://rtai.dk/cgi-bin/gratiswiki.pl?How_To_Implement_A_New_Skin The reasons why the Xenomai project, was made a separate project from RTAI is explained in the following post on RTAI mailing list : https://mail.rtai.org/pipermail/rtai/2005-October/013155.html -- Gilles Chanteperdrix.
Re: [Xenomai-core] Scheduling while atomic
Turned off: o nucleus debugging o ipipe stats o ipipe tracing o ishield The problem persists. Also tried three tasks, with same result. With one task, there is no problem. Jeroen.
Re: [Xenomai-core] Initialization of a nucleus pod
Thank you for your response So rootcb isn't the "scheduler task". I was thinking it was this task which was determining what thread to run, depending of its parameters (priority, periodicity, scheduling mode). I go back to the code to understand how it work ... Germain > > xnthread_init does part of the initialization. The low level part of > rootcb (its xnarchtcb_t member) is initialized twice, first by the call > to xnarch_init_tcb in xnthread_init, and then overriden by > xnarch_init_root_tcb in xnpod_init. > > For any other thread than root, the thread would be given a stack and > entry point by the call to xnarch_init_thread in xnpod_start_thread. But > the root thread is Xenomai idle task, a placeholder for whatever task > Linux is currenty running. At the time where xnpod_init is called, the > root thread is the current context, so already has a stack and is > already running. > > -- > > > Gilles Chanteperdrix. > ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Missing IRQ end function on PowerPC
Gilles Chanteperdrix wrote: Wolfgang Grandegger wrote: > Therefore we need a dedicated function to re-enable interrupts in the > ISR. We could name it *_end_irq, but maybe *_enable_isr_irq is more > obvious. On non-PPC archs it would translate to *_irq_enable. I > realized, that *_irq_enable is used in various place/skins and therefore > I have not yet provided a patch. The function xnarch_irq_enable seems to be called in only two functions, xintr_enable and xnintr_irq_handler when the flag XN_ISR_ENABLE is set. But the user may want to re-enable the interrupt without using XN_ISR_ENABLE as well. In any case, since I am not sure if this has to be done at the Adeos level or in Xenomai, we will wait for Philippe to come back and decide. In both, I guess. OK and thanks. Wolfgang. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Missing IRQ end function on PowerPC
Wolfgang Grandegger wrote: > Therefore we need a dedicated function to re-enable interrupts in the > ISR. We could name it *_end_irq, but maybe *_enable_isr_irq is more > obvious. On non-PPC archs it would translate to *_irq_enable. I > realized, that *_irq_enable is used in various place/skins and therefore > I have not yet provided a patch. The function xnarch_irq_enable seems to be called in only two functions, xintr_enable and xnintr_irq_handler when the flag XN_ISR_ENABLE is set. In any case, since I am not sure if this has to be done at the Adeos level or in Xenomai, we will wait for Philippe to come back and decide. -- Gilles Chanteperdrix. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Missing IRQ end function on PowerPC
Gilles Chanteperdrix wrote:
Wolfgang Grandegger wrote:
> Hello,
>
> with RTnet over Xenomai and Linux 2.4 on PowerPC I realized that Xenomai
> does not distinguish between a normal IRQ enable and an IRQ unmask at
> the end of an ISR (to reenable the IRQ). In the latter case the IRQ
> should be enabled on PowerPC as shown:
>
> if (rthal_irq_descp(irq)->handler->end != NULL)
> rthal_irq_descp(irq)->handler->end(irq);
> else
> rthal_irq_descp(irq)->handler->enable(irq);
>
> To handle this case properly, we need to different functions, I think.
I am not sure I understand what you mean. Would you want functions
rthal_end_irq and xnarch_end_irq added and that this xnarch_end_irq
would be called in xnintr_irq_handler when XN_ISR_ENABLE is set ?
Yes, that's what I have basically done to get the RTnet SCC enet driver
working on my MPC8xx module. In arch/ppc/kernel/irq.c you can see how
Linux re-enables interrupts at the end of it's ISR (see
http://cvs.gna.org/cvsweb/linux/v2.4/2.4.25-ppc/arch/ppc/kernel/irq.c?rev=1.1;cvsroot=adeos):
507: * The ->end() handler has to deal with interrupts which got
508: * disabled while the handler was running.
509: */
510: if (desc->handler) {
511: if (desc->handler->end)
512: desc->handler->end(irq);
513: else if (desc->handler->enable)
514: desc->handler->enable(irq);
In PPC Linux 2.6 things are a bit different. The "end" functions seems
to be mandatory now (I have to check more carefully).
Therefore we need a dedicated function to re-enable interrupts in the
ISR. We could name it *_end_irq, but maybe *_enable_isr_irq is more
obvious. On non-PPC archs it would translate to *_irq_enable. I
realized, that *_irq_enable is used in various place/skins and therefore
I have not yet provided a patch.
Wolfgang.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Initialization of a nucleus pod
Germain Olivier wrote: > Hello > > I am trying to understand how a pod is initialized. > > I think it start with xncore_attach() from core.c, then with xnpod_init from > pod.c > But here (in xnpod_init) there is something not clear about the root thread > creation. > > It use xnthread_init(&sched->rootcb, ...), but I don't see where > &sched->rootcb is initialized xnthread_init does part of the initialization. The low level part of rootcb (its xnarchtcb_t member) is initialized twice, first by the call to xnarch_init_tcb in xnthread_init, and then overriden by xnarch_init_root_tcb in xnpod_init. For any other thread than root, the thread would be given a stack and entry point by the call to xnarch_init_thread in xnpod_start_thread. But the root thread is Xenomai idle task, a placeholder for whatever task Linux is currenty running. At the time where xnpod_init is called, the root thread is the current context, so already has a stack and is already running. -- Gilles Chanteperdrix. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Missing IRQ end function on PowerPC
Wolfgang Grandegger wrote: > Hello, > > with RTnet over Xenomai and Linux 2.4 on PowerPC I realized that Xenomai > does not distinguish between a normal IRQ enable and an IRQ unmask at > the end of an ISR (to reenable the IRQ). In the latter case the IRQ > should be enabled on PowerPC as shown: > > if (rthal_irq_descp(irq)->handler->end != NULL) > rthal_irq_descp(irq)->handler->end(irq); > else > rthal_irq_descp(irq)->handler->enable(irq); > > To handle this case properly, we need to different functions, I think. I am not sure I understand what you mean. Would you want functions rthal_end_irq and xnarch_end_irq added and that this xnarch_end_irq would be called in xnintr_irq_handler when XN_ISR_ENABLE is set ? -- Gilles Chanteperdrix. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] RTAI vs XENOMAI
Doyle, Alan \(Siemens\) wrote: > Hi, > > I'm looking into porting an embedded application using Accelerated > Technologies 'Nucleus' RTOS to a real time Linux variant. RTAI is the > preferred approach but on looking into available documentation I have > discovered Xenomai which seems to be designed to solve this sort of > problem. However as there is no existing emulator for Nucleus on Xenomai > I would have to write one so I'm unsure whether there would then be any > benefit. Could somebody advise me as to the pros and cons of porting to > RTAI or Xenomai. Using Xenomai would ease writing a skin for the nucleus RTOS. Philippe once wrote a mail on how to write a new skin, which you will find on rtai.dk: http://rtai.dk/cgi-bin/gratiswiki.pl?How_To_Implement_A_New_Skin The reasons why the Xenomai project, was made a separate project from RTAI is explained in the following post on RTAI mailing list : https://mail.rtai.org/pipermail/rtai/2005-October/013155.html -- Gilles Chanteperdrix. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Scheduling while atomic
Turned off: o nucleus debugging o ipipe stats o ipipe tracing o ishield The problem persists. Also tried three tasks, with same result. With one task, there is no problem. Jeroen. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Scheduling while atomic
Hold on. Just crashed without the file access: please disregard last post. Jeroen.
[Xenomai-core] Scheduling while atomic
Hm. When I remove the output() from both tasks, all seems fine. Jeroen.
