date:20120105

[Xenomai-help] [PATCH] fix mscan init on mpc5121

2012-01-05 Thread Fabrice Gasnier

insmod xeno_rtcan_mscan gets stuck on MPC5121.
driver enters an endless loop at init.
Adapt it using linux driver behavior.

Signed-off-by: Fabrice Gasnier 
---
 ksrc/drivers/can/mscan/rtcan_mscan.c |   38 -
 1 files changed, 36 insertions(+), 2 deletions(-)

diff --git a/ksrc/drivers/can/mscan/rtcan_mscan.c 
b/ksrc/drivers/can/mscan/rtcan_mscan.c
index d25fc5a..edd590e 100644
--- a/ksrc/drivers/can/mscan/rtcan_mscan.c
+++ b/ksrc/drivers/can/mscan/rtcan_mscan.c
@@ -40,6 +40,8 @@
 #include "rtcan_mscan_regs.h"
 #include "rtcan_mscan.h"
 
+#define MSCAN_SET_MODE_RETRIES 255
+
 /**
  *  Reception Interrupt handler
  *
@@ -306,11 +308,41 @@ static int rtcan_mscan_mode_stop(struct rtcan_device *dev,
 
/* Switch to sleep mode */
setbits8(®s->canctl0, MSCAN_SLPRQ);
+   reg = in_8(®s->canctl1);
+   while (!(reg & MSCAN_SLPAK) &&
+   (rinit < MSCAN_SET_MODE_RETRIES)) {
+   if (likely(lock_ctx != NULL))
+   rtdm_lock_put_irqrestore(&dev->device_lock, *lock_ctx);
+   /* Busy sleep 1 microsecond */
+   rtdm_task_busy_sleep(1000);
+   if (likely(lock_ctx != NULL))
+   rtdm_lock_get_irqsave(&dev->device_lock, *lock_ctx);
+   rinit++;
+   reg = in_8(®s->canctl1);
+   }
+   /*
+* The mscan controller will fail to enter sleep mode,
+* while there are irregular activities on bus, like
+* somebody keeps retransmitting. This behavior is
+* undocumented and seems to differ between mscan built
+* in mpc5200b and mpc5200. We proceed in that case,
+* since otherwise the slprq will be kept set and the
+* controller will get stuck. NOTE: INITRQ or CSWAI
+* will abort all active transmit actions, if still
+* any, at once.
+*/
+   if (rinit >= MSCAN_SET_MODE_RETRIES)
+   rtdm_printk("rtcan_mscan: device failed to enter sleep mode. "
+   "We proceed anyhow.\n");
+   else
+   dev->state = CAN_STATE_SLEEPING;
+
+   rinit = 0;
setbits8(®s->canctl0, MSCAN_INITRQ);
 
reg = in_8(®s->canctl1);
-   while (!(reg & MSCAN_SLPAK) ||
-  !(reg & MSCAN_INITAK)) {
+   while (!(reg & MSCAN_INITAK) &&
+   (rinit < MSCAN_SET_MODE_RETRIES)) {
if (likely(lock_ctx != NULL))
rtdm_lock_put_irqrestore(&dev->device_lock, *lock_ctx);
/* Busy sleep 1 microsecond */
@@ -320,6 +352,8 @@ static int rtcan_mscan_mode_stop(struct rtcan_device *dev,
rinit++;
reg = in_8(®s->canctl1);
}
+   if (rinit >= MSCAN_SET_MODE_RETRIES)
+   ret = -ENODEV;
 
/* Volatile state could have changed while we slept busy. */
dev->state = CAN_STATE_STOPPED;
-- 
1.7.0.4


___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help

[Xenomai-help] Problems with installation

2012-01-05 Thread Santiago Focke

Hi all

I'm quite new with Linux and Xenomai. I'm using Ubunto kernel
2.6.32-24-generic. I tied to install Xenomai-2.6 following the
README.INSTALL document. First of all I cloned the GIT repository in

/usr/src/xenomai-2.6

After that, I tried to run the prepare-kernel.sh script as follows:

/usr/src/xenomai-2.6/scripts/prepare-kernel.sh
--linux=/usr/src/linux-headers-2.6.32-24-generic/

I select the default target architecture with no problems

Target architecture [default i686]:

But when I select the default I-pipe patch i get the following:

I-pipe patch [default /dev/null]:
prepare-kernel.sh: cannot read I-pipe patch from /dev/null

What should I do?

Thanks in advance,


-- 
Santiago
___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help

[Xenomai-help] RTDM and spi

2012-01-05 Thread Terry Fryar

Using the RTDM api with Xen 2.6 to develop a linux driver.  
 
Basically have an ISR registered using rtdm_irq_request() that is triggered
from a gpio pin.  ISR works fine.  Inside ISR, the only thing done is a
rtdm_event_signal() on an event.
 
Then, I have a task created using rtdm_task_init() that is waiting on the
event using rtdm_event_timedwait().
 
So far, so good...all works.  But, in the task I am making an SPI call after
the event is signaled using spi_message_add_tail() and spi_sync() and that's
where I get this:
 
BUG: sleeping function called from invalid context at kernel/mutex.c:278
[   98.449178] in_atomic(): 1, irqs_disabled(): 0, pid: -555875760, name:
vÿÿýÿ¿·½ÿ§ÿÿõ>ÿÿýw¿@ÞÞPÞÞ
[   98.458686] INFO: lockdep is turned off.
[   98.462811] [] (unwind_backtrace+0x0/0xe0) from []
(mutex_lock_nested+0x24/0x384)
[   98.472501] [] (mutex_lock_nested+0x24/0x384) from []
(__spi_sync+0x88/0xd8)
[   98.481730] [] (__spi_sync+0x88/0xd8) from []
(irqdrv_task+0x44/0xd4 [irqdrv])
[   98.491149] [] (irqdrv_task+0x44/0xd4 [irqdrv]) from
[] (xnarch_thread_trampoline+0x20/0x2c)
[   98.501845] [] (xnarch_thread_trampoline+0x20/0x2c) from
[] (__xnpod_schedule+0x5cc/0xa54)
[   98.512355] [] (__xnpod_schedule+0x5cc/0xa54) from []
(0xfff7febf)
[   98.520674] Xenomai: suspending kernel thread bf008180 ('irqdrvTask') at
0xc00a92f8 after exception #0x0

I have tried this inside a kthread and it works fine.  I can also try the
spi stuff without being triggered by an IRQ, and I get the same error.  I
know this is something simple???
___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help

Re: [Xenomai-help] RTDM and spi

2012-01-05 Thread Philippe Gerum


On 01/05/2012 11:12 PM, Terry Fryar wrote:

Using the RTDM api with Xen 2.6 to develop a linux driver.
Basically have an ISR registered using *rtdm_irq_request*()that is
triggered from a gpio pin. ISR works fine. Inside ISR, the only thing
done is a *rtdm_event_signal*() on an event.
Then, I have a task created using *rtdm_task_init*() that is waiting on
the event using *rtdm_event_timedwait*().
So far, so good...all works. But, in the task I am making an SPI call
after the event is signaled using spi_message_add_tail() and spi_sync()
and that's where I get this:
BUG: sleeping function called from invalid context at kernel/mutex.c:278
[ 98.449178] in_atomic(): 1, irqs_disabled(): 0, pid: -555875760, name:
vÿÿýÿ¿·½ÿ§ÿÿõ>ÿÿýw¿@ÞÞPÞÞ
[ 98.458686] INFO: lockdep is turned off.
[ 98.462811] [] (unwind_backtrace+0x0/0xe0) from []
(mutex_lock_nested+0x24/0x384)
[ 98.472501] [] (mutex_lock_nested+0x24/0x384) from
[] (__spi_sync+0x88/0xd8)
[ 98.481730] [] (__spi_sync+0x88/0xd8) from []
(irqdrv_task+0x44/0xd4 [irqdrv])
[ 98.491149] [] (irqdrv_task+0x44/0xd4 [irqdrv]) from
[] (xnarch_thread_trampoline+0x20/0x2c)
[ 98.501845] [] (xnarch_thread_trampoline+0x20/0x2c) from
[] (__xnpod_schedule+0x5cc/0xa54)
[ 98.512355] [] (__xnpod_schedule+0x5cc/0xa54) from
[] (0xfff7febf)
[ 98.520674] Xenomai: suspending kernel thread bf008180 ('irqdrvTask')
at 0xc00a92f8 after exception #0x0
I have tried this inside a kthread and it works fine. I can also try the
spi stuff without being triggered by an IRQ, and I get the same error. I
know this is something simple???


You may not call the regular Linux kernel routines from a real-time 
context. You have two kernels running side by side, Linux and Xenomai, 
unsynchronized. Your RTDM driver is entering __spi_sync() over a 
non-Linux context, this can't work since that context may have preempted 
Linux anywhere, including in the middle of what Linux thinks is an 
atomic section.


Any kernel code you want to call from the real-time co-kernel has to be 
adapted to support this. Specifically, you cannot run the regular SPI 
stack over a real-time RTDM context.






___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help



--
Philippe.

___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help

Re: [Xenomai-help] RTDM and spi

2012-01-05 Thread Terry Fryar

Ah...simple enough!  One question though...are the xenomai sync services
items and irq functions available for non-RT kernel threads??

-Original Message-
From: Philippe Gerum [mailto:r...@xenomai.org] 
Sent: Thursday, January 05, 2012 4:25 PM
To: Terry Fryar
Cc: xenomai-help@gna.org
Subject: Re: [Xenomai-help] RTDM and spi

On 01/05/2012 11:12 PM, Terry Fryar wrote:
> Using the RTDM api with Xen 2.6 to develop a linux driver.
> Basically have an ISR registered using *rtdm_irq_request*()that is 
> triggered from a gpio pin. ISR works fine. Inside ISR, the only thing 
> done is a *rtdm_event_signal*() on an event.
> Then, I have a task created using *rtdm_task_init*() that is waiting 
> on the event using *rtdm_event_timedwait*().
> So far, so good...all works. But, in the task I am making an SPI call 
> after the event is signaled using spi_message_add_tail() and 
> spi_sync() and that's where I get this:
> BUG: sleeping function called from invalid context at 
> kernel/mutex.c:278 [ 98.449178] in_atomic(): 1, irqs_disabled(): 0, pid:
-555875760, name:
> vÿÿýÿ¿·½ÿ§ÿÿõ>ÿÿýw¿@ÞÞPÞÞ
> [ 98.458686] INFO: lockdep is turned off.
> [ 98.462811] [] (unwind_backtrace+0x0/0xe0) from 
> []
> (mutex_lock_nested+0x24/0x384)
> [ 98.472501] [] (mutex_lock_nested+0x24/0x384) from 
> [] (__spi_sync+0x88/0xd8) [ 98.481730] [] 
> (__spi_sync+0x88/0xd8) from []
> (irqdrv_task+0x44/0xd4 [irqdrv])
> [ 98.491149] [] (irqdrv_task+0x44/0xd4 [irqdrv]) from 
> [] (xnarch_thread_trampoline+0x20/0x2c)
> [ 98.501845] [] (xnarch_thread_trampoline+0x20/0x2c) from 
> [] (__xnpod_schedule+0x5cc/0xa54) [ 98.512355] [] 
> (__xnpod_schedule+0x5cc/0xa54) from [] (0xfff7febf) [ 
> 98.520674] Xenomai: suspending kernel thread bf008180 ('irqdrvTask') 
> at 0xc00a92f8 after exception #0x0 I have tried this inside a kthread 
> and it works fine. I can also try the spi stuff without being 
> triggered by an IRQ, and I get the same error. I know this is 
> something simple???

You may not call the regular Linux kernel routines from a real-time context.
You have two kernels running side by side, Linux and Xenomai,
unsynchronized. Your RTDM driver is entering __spi_sync() over a non-Linux
context, this can't work since that context may have preempted Linux
anywhere, including in the middle of what Linux thinks is an atomic section.

Any kernel code you want to call from the real-time co-kernel has to be
adapted to support this. Specifically, you cannot run the regular SPI stack
over a real-time RTDM context.

>
>
>
> ___
> Xenomai-help mailing list
> Xenomai-help@gna.org
> https://mail.gna.org/listinfo/xenomai-help


-- 
Philippe.


___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help

Re: [Xenomai-help] RTDM and spi

2012-01-05 Thread Philippe Gerum


On 01/05/2012 11:28 PM, Terry Fryar wrote:

Ah...simple enough!  One question though...are the xenomai sync services
items and irq functions available for non-RT kernel threads??


IRQ related routines? like request, enable, disable: yes. It's even 
recommended to use them in that context actually.


Xenomai blocking services can only be used over a Xenomai thread, that 
is a golden rule. Reason: to wait for a sync, the thread has to be held 
by the scheduler of the kernel in question while it sleeps. Only Xenomai 
threads have the required internal data to allow the Xenomai scheduler 
to hold them.




-Original Message-
From: Philippe Gerum [mailto:r...@xenomai.org]
Sent: Thursday, January 05, 2012 4:25 PM
To: Terry Fryar
Cc: xenomai-help@gna.org
Subject: Re: [Xenomai-help] RTDM and spi

On 01/05/2012 11:12 PM, Terry Fryar wrote:

Using the RTDM api with Xen 2.6 to develop a linux driver.
Basically have an ISR registered using *rtdm_irq_request*()that is
triggered from a gpio pin. ISR works fine. Inside ISR, the only thing
done is a *rtdm_event_signal*() on an event.
Then, I have a task created using *rtdm_task_init*() that is waiting
on the event using *rtdm_event_timedwait*().
So far, so good...all works. But, in the task I am making an SPI call
after the event is signaled using spi_message_add_tail() and
spi_sync() and that's where I get this:
BUG: sleeping function called from invalid context at
kernel/mutex.c:278 [ 98.449178] in_atomic(): 1, irqs_disabled(): 0, pid:

-555875760, name:

vÿÿýÿ¿·½ÿ§ÿÿõ>ÿÿýw¿@ÞÞPÞÞ
[ 98.458686] INFO: lockdep is turned off.
[ 98.462811] [] (unwind_backtrace+0x0/0xe0) from
[]
(mutex_lock_nested+0x24/0x384)
[ 98.472501] [] (mutex_lock_nested+0x24/0x384) from
[] (__spi_sync+0x88/0xd8) [ 98.481730] []
(__spi_sync+0x88/0xd8) from []
(irqdrv_task+0x44/0xd4 [irqdrv])
[ 98.491149] [] (irqdrv_task+0x44/0xd4 [irqdrv]) from
[] (xnarch_thread_trampoline+0x20/0x2c)
[ 98.501845] [] (xnarch_thread_trampoline+0x20/0x2c) from
[] (__xnpod_schedule+0x5cc/0xa54) [ 98.512355] []
(__xnpod_schedule+0x5cc/0xa54) from [] (0xfff7febf) [
98.520674] Xenomai: suspending kernel thread bf008180 ('irqdrvTask')
at 0xc00a92f8 after exception #0x0 I have tried this inside a kthread
and it works fine. I can also try the spi stuff without being
triggered by an IRQ, and I get the same error. I know this is
something simple???


You may not call the regular Linux kernel routines from a real-time context.
You have two kernels running side by side, Linux and Xenomai,
unsynchronized. Your RTDM driver is entering __spi_sync() over a non-Linux
context, this can't work since that context may have preempted Linux
anywhere, including in the middle of what Linux thinks is an atomic section.

Any kernel code you want to call from the real-time co-kernel has to be
adapted to support this. Specifically, you cannot run the regular SPI stack
over a real-time RTDM context.





___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help






--
Philippe.

___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help

Re: [Xenomai-help] RTDM and spi

2012-01-05 Thread Terry Fryar

So, this would cover the rtdm_event_timedwait(), for example??  This would
*not* work in a non-realtime thread..correct?? 

-Original Message-
From: Philippe Gerum [mailto:r...@xenomai.org] 
Sent: Thursday, January 05, 2012 4:44 PM
To: Terry Fryar
Cc: xenomai-help@gna.org
Subject: Re: [Xenomai-help] RTDM and spi

On 01/05/2012 11:28 PM, Terry Fryar wrote:
> Ah...simple enough!  One question though...are the xenomai sync 
> services items and irq functions available for non-RT kernel threads??

IRQ related routines? like request, enable, disable: yes. It's even
recommended to use them in that context actually.

Xenomai blocking services can only be used over a Xenomai thread, that is a
golden rule. Reason: to wait for a sync, the thread has to be held by the
scheduler of the kernel in question while it sleeps. Only Xenomai threads
have the required internal data to allow the Xenomai scheduler to hold them.

>
> -Original Message-
> From: Philippe Gerum [mailto:r...@xenomai.org]
> Sent: Thursday, January 05, 2012 4:25 PM
> To: Terry Fryar
> Cc: xenomai-help@gna.org
> Subject: Re: [Xenomai-help] RTDM and spi
>
> On 01/05/2012 11:12 PM, Terry Fryar wrote:
>> Using the RTDM api with Xen 2.6 to develop a linux driver.
>> Basically have an ISR registered using *rtdm_irq_request*()that is 
>> triggered from a gpio pin. ISR works fine. Inside ISR, the only thing 
>> done is a *rtdm_event_signal*() on an event.
>> Then, I have a task created using *rtdm_task_init*() that is waiting 
>> on the event using *rtdm_event_timedwait*().
>> So far, so good...all works. But, in the task I am making an SPI call 
>> after the event is signaled using spi_message_add_tail() and
>> spi_sync() and that's where I get this:
>> BUG: sleeping function called from invalid context at
>> kernel/mutex.c:278 [ 98.449178] in_atomic(): 1, irqs_disabled(): 0, pid:
> -555875760, name:
>> vÿÿýÿ¿·½ÿ§ÿÿõ>ÿÿýw¿@ÞÞPÞÞ
>> [ 98.458686] INFO: lockdep is turned off.
>> [ 98.462811] [] (unwind_backtrace+0x0/0xe0) from 
>> []
>> (mutex_lock_nested+0x24/0x384)
>> [ 98.472501] [] (mutex_lock_nested+0x24/0x384) from 
>> [] (__spi_sync+0x88/0xd8) [ 98.481730] []
>> (__spi_sync+0x88/0xd8) from []
>> (irqdrv_task+0x44/0xd4 [irqdrv])
>> [ 98.491149] [] (irqdrv_task+0x44/0xd4 [irqdrv]) from 
>> [] (xnarch_thread_trampoline+0x20/0x2c)
>> [ 98.501845] [] (xnarch_thread_trampoline+0x20/0x2c) from 
>> [] (__xnpod_schedule+0x5cc/0xa54) [ 98.512355] []
>> (__xnpod_schedule+0x5cc/0xa54) from [] (0xfff7febf) [ 
>> 98.520674] Xenomai: suspending kernel thread bf008180 ('irqdrvTask') 
>> at 0xc00a92f8 after exception #0x0 I have tried this inside a kthread 
>> and it works fine. I can also try the spi stuff without being 
>> triggered by an IRQ, and I get the same error. I know this is 
>> something simple???
>
> You may not call the regular Linux kernel routines from a real-time
context.
> You have two kernels running side by side, Linux and Xenomai, 
> unsynchronized. Your RTDM driver is entering __spi_sync() over a 
> non-Linux context, this can't work since that context may have 
> preempted Linux anywhere, including in the middle of what Linux thinks is
an atomic section.
>
> Any kernel code you want to call from the real-time co-kernel has to 
> be adapted to support this. Specifically, you cannot run the regular 
> SPI stack over a real-time RTDM context.
>
>>
>>
>>
>> ___
>> Xenomai-help mailing list
>> Xenomai-help@gna.org
>> https://mail.gna.org/listinfo/xenomai-help
>
>


--
Philippe.


___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help

Re: [Xenomai-help] unresolved symbol - check the xenomai installation

2012-01-05 Thread Jakub Nowacki


On 04/01/12 17:45, Gilles Chanteperdrix wrote:


This looks bad. Please re-run latency with no argument. If should
normally produce a report about min/average/max latency every second. If
it does not, I would recommend restarting the installation from scratch:
- first uninstalling any installed version, running "make uninstall" in
the build directory, this for xenomai 2.4.4 and 2.6.0.
- re-run prepare-kernel, recompile the kernel, leaving the xenomai
configuration options to their default value.

I have a similar problem trying to install xenomai 2.6.0. In my case 
latency works correctly, but trying to compile examples gives me the 
same 'unresolved reference' error. I noticed this first trying to 
compile RTXI, which also gives me


/usr/xenomai/lib/libnative.so: undefined reference to `xeno_current'
/usr/xenomai/lib/libnative.so: undefined reference to `xeno_sem_heap'
/usr/xenomai/lib/libnative.so: undefined reference to 
`xeno_sigshadow_install_once'

/usr/xenomai/lib/libnative.so: undefined reference to `xeno_set_current'
/usr/xenomai/lib/libnative.so: undefined reference to `xeno_map_heap'
/usr/xenomai/lib/libnative.so: undefined reference to `xnarch_tsc_to_ns'
/usr/xenomai/lib/libnative.so: undefined reference to 
`xeno_handle_mlock_alert'

/usr/xenomai/lib/libnative.so: undefined reference to `xeno_fault_stack'
/usr/xenomai/lib/libnative.so: undefined reference to 
`xeno_set_current_mode'

/usr/xenomai/lib/libnative.so: undefined reference to `xeno_bind_skin_opt'
/usr/xenomai/lib/libnative.so: undefined reference to `xeno_current_mode'
/usr/xenomai/lib/libnative.so: undefined reference to `xnarch_ns_to_tsc'

I did it before with Xenomai 2.5.6 and did not recall such a linking 
problems. I read before that it might be causes by cross-compilation 
being messed up, but in that case I do default compilation on linux 
2.6.38.8. I did not try 2.5.6 again to check if the problem remains for 
2.5.6, I can try to do that.


Best wishes,

Jakub

___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help

[Xenomai-help] [PATCH] fix mscan init on mpc5121

[Xenomai-help] Problems with installation

[Xenomai-help] RTDM and spi

Re: [Xenomai-help] RTDM and spi

Re: [Xenomai-help] RTDM and spi

Re: [Xenomai-help] RTDM and spi

Re: [Xenomai-help] RTDM and spi

Re: [Xenomai-help] unresolved symbol - check the xenomai installation

8 matches

Site Navigation

Mail list logo

Footer information