[Xenomai-help] Driver port to xenomai

[Xenomai-help] Driver port to xenomai

[Sven Kjaergaard]

Hi,

I have to port a driver mainly written for VxWorks to Xenomai. In this
way, I link it with the vxworks skin and it built successfully.

But when inserting the module in the kernel (with debug nucleus set)
the following  error occur meaning that the driver is in the linux
domain and not in the priority one. What did I missed ? Did I have to
convert some call to rthal_ ones for those where the corresponding
function exists ? I don't think rtdm is mandatory for driver writting
?

TIA for any tips,
Sven

Xenomai: fatal: attempt to suspend root thread ROOT
  CPU  PID    PRI      TIMEOUT  STAT      NAME
  0    0       -1      0        00400080  ROOT
Timer: periodic [tickval=1000000 ns, elapsed=10965]

[<c00223f0>] (show_stack+0x0/0x54) from [<c0060d34>] (xnpod_suspend_thread
+0x24c/0)[<c0060ae8>] (xnpod_suspend_thread+0x0/0x58c) from [<bf006418>]
(taskDelay+0x7c/0x)[<bf00639c>] (taskDelay+0x0/0x120 [xeno_vxworks]) from
[<bf011130>] (bus_init+) r6 = BF016304  r5 = C1CAF400  r4 = 000003E8
[<bf011090>] (bus_init+0x0/0x6a4 [rtconbus]) from [<bf01a0f8>]
(rtconbus_init+) r7 = BF015B00  r6 = C28633FC  r5 = C1CAF400  r4 = BF015C80
[<bf01a000>] (rtconbus_init+0x0/0x284 [rtconbus]) from [<c0051c6c>]
(sys_init_modu) r4 = BF015B00 [<c0051b34>] (sys_init_module+0x0/0x15b8)
from [<c001e3a4>] (ret_fast_syscall+0x0/)

Re: [Xenomai-help] Driver port to xenomai

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 2106 bytes --]

Sven Kjaergaard wrote:
> Hi,
> 
> I have to port a driver mainly written for VxWorks to Xenomai. In this
> way, I link it with the vxworks skin and it built successfully.
> 
> But when inserting the module in the kernel (with debug nucleus set)
> the following  error occur meaning that the driver is in the linux
> domain and not in the priority one. What did I missed ? Did I have to
> convert some call to rthal_ ones for those where the corresponding
> function exists ? I don't think rtdm is mandatory for driver writting
> ?

RTDM is not mandatory, just recommended for future driver development.
Mainly because it increases portability (and re-usability) across skins
and motivates the definition of generic driver interfaces.

> 
> TIA for any tips,
> Sven
> 
> Xenomai: fatal: attempt to suspend root thread ROOT
>   CPU  PID    PRI      TIMEOUT  STAT      NAME
>   0    0       -1      0        00400080  ROOT
> Timer: periodic [tickval=1000000 ns, elapsed=10965]
> 
> [<c00223f0>] (show_stack+0x0/0x54) from [<c0060d34>] (xnpod_suspend_thread
> +0x24c/0)[<c0060ae8>] (xnpod_suspend_thread+0x0/0x58c) from [<bf006418>]
> (taskDelay+0x7c/0x)[<bf00639c>] (taskDelay+0x0/0x120 [xeno_vxworks]) from
> [<bf011130>] (bus_init+) r6 = BF016304  r5 = C1CAF400  r4 = 000003E8
> [<bf011090>] (bus_init+0x0/0x6a4 [rtconbus]) from [<bf01a0f8>]
> (rtconbus_init+) r7 = BF015B00  r6 = C28633FC  r5 = C1CAF400  r4 = BF015C80
> [<bf01a000>] (rtconbus_init+0x0/0x284 [rtconbus]) from [<c0051c6c>]
> (sys_init_modu) r4 = BF015B00 [<c0051b34>] (sys_init_module+0x0/0x15b8)
> from [<c001e3a4>] (ret_fast_syscall+0x0/)

Argh, your mailer makes reading this backtrace not very handy. Anyway,
you called taskDelay over the root thread, here in the context of
module_init of your driver. Either switch to true Linux suspension
services (usleep, msleep, etc.) for initialisation work or move that
work already into a (temporary?) VxWorks task.

[There is the chance that we will do such context wrapping on demand in
a future release, but that doesn't help right now.]

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]