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
> 1000
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 \
-
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 pa
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_enab
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/sk
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
> 1000
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
> sh
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_
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
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 \
-
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 d
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.
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 pa
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_enab
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/sk
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
> sh
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_
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
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 d
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:
Hold on. Just crashed without the file access: please disregard last post.
Jeroen.
Hm.
When I remove the output() from both tasks, all seems fine.
Jeroen.
22 matches
Mail list logo
