Linux and RTAI on the Motorola VME Boards

Linux and RTAI on the Motorola VME Boards

[Oliver Korpilla]

Hello!

I'm doing a university project on Linux in realtime applications.

The ultimate goal is to evaluate realtime options for the MVME 2100,
MVME 5500, and VMIVME 7050 (ok, that's an Intel one, just mentioned it
for completeness :) ).

Since hard realtime is preferred, kernel preemption doesn't seem to be
good enough, so I wanted to focus on RTAI. I found several Linux drivers
for CPU and board hardware, and several drivers for the Tundra Universe
II PCI-VME bridge.

Unfortunately, I didn't find very much documentation on RTAI. I'm
actually wondering what I need to communicate with the VME bus in
realtime. Can I safely call the Linux drivers functions? Do I need to
use a modified version of the driver? What features in a driver do not
mix with RTAI?

I've read on the list Xavier Grave seemed to have done something very
similar on the MVME 5500, but he seems to have not published all of it,
at least not now.

On a similar issue:
I found a discussion about problems using the open_pic driver with the
MVME 2100, and considerations about a possible rewrite of the driver to
accomodate more flexibility. Has someone done it by now?

Thanks in advance,
Oliver Korpilla
CS student at the University of Applied Sciences at Landshut, Germany

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Linux and RTAI on the Motorola VME Boards

[Marius Groeger]

On Thu, 18 Mar 2004, Oliver Korpilla wrote:

> Unfortunately, I didn't find very much documentation on RTAI. I'm
> actually wondering what I need to communicate with the VME bus in
> realtime. Can I safely call the Linux drivers functions? Do I need to
> use a modified version of the driver? What features in a driver do not
> mix with RTAI?

RTAI is a kernel on its own. It has an own scheduler and API to control (eg.
to create threads and allowing them to synchronize with each other).
Therefore an RTAI thread cannot call Linux kernel services.

However, RTAI does share the kernel memory map, so any memory region mapped
by the Linux kernel (or a driver) is also visible to RTAI.

I don't know the VME driver you're about to use, but you should be
able to safely use the VME memory regions it maps.

BTW, you may want to join the RTAI list, where these kinds of
questions are better directed to.

Regards,
Marius

--
Marius Groeger <mgroeger@sysgo.com> | Project Manager

SYSGO Real-Time Solutions AG | Embedded and Real-Time Software
Am Pfaffenstein 14 | 55270 Klein-Winternheim, Germany

Voice: +49-6136-9948-0 | FAX: +49-6136-9948-10
www.sysgo.com | www.elinos.com | www.osek.de | www.imerva.com


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Linux and RTAI on the Motorola VME Boards

[Oliver Korpilla]

>However, RTAI does share the kernel memory map, so any memory region mapped
>by the Linux kernel (or a driver) is also visible to RTAI.
>
>
Actually, from reading the RTAI mailing list, it may just be possible to
let a Linux driver establish the necessary mappings, and use those in a
RTAI task. If I catch the interrupts related to that device (that info
should be obtainable , too, on task initialization, where real-time
isn't needed) and process them only in the RTAI space, using the
established mappings, this could actually be sufficient for my purposes.
I first have to evaluate that.

>I don't know the VME driver you're about to use, but you should be
>able to safely use the VME memory regions it maps.
>
>BTW, you may want to join the RTAI list,
>
I did. :)

Since enough of the entries on this list seem to refer to VME stuff on
MVME boards, and solutions with RTAI and Linux were proposed or offered
here as well (for example by Xavier Grave), I thought it to be wise to
drop a mail here still.

Of course I would be grateful on any help about drivers, stuff, and
(open?) BSPs about those boards (MVME 2100, MVME 5500) in general, too! :)

Thanks,
Oliver Korpilla
CS Student at the University of Applied Sciences at Landshut, Germany

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/