IP Layer on VME-Bus

IP Layer on VME-Bus

[H. Wiese]

Hello,

we develop a driver which enables us to use an ip layer on top of the vme-bus
technology. Now we got some problems with coding the driver. We already have
an old version of this driver (called "dpn") which works well but has no use
for us anymore since we upgraded our system from kernel 2.2.14 to 2.6.7. So
now we have to create a new driver.

The old driver established the ip layer by accessing the dual port ram of
the VME bus, which is based on a Tundra Universe II Chipset. This enables
us to transfer data, ping etc. between active VME-modules using the
VME-bus. Very useful.

Well, the problem we will surely run into is: will the driver work as fine as
the old one if we only recreate the initialization functions working with the
new kernel function set (e.g. wait_event_interruptible instead of
interruptible_sleep_on etc.), copy the essential functions from the old
driver
to the new one and alter them a little to work with the new kernel functions?
Or is there anything else to put an eye on?


Thankx a lot

kind regards
Hendrik

Re: IP Layer on VME-Bus

[linux-os]

On Wed, 3 Nov 2004, H. Wiese wrote:

> Hello,
>
> we develop a driver which enables us to use an ip layer on top of the vme-bus
> technology. Now we got some problems with coding the driver. We already have
> an old version of this driver (called "dpn") which works well but has no use
> for us anymore since we upgraded our system from kernel 2.2.14 to 2.6.7. So
> now we have to create a new driver.
>
> The old driver established the ip layer by accessing the dual port ram of
> the VME bus, which is based on a Tundra Universe II Chipset. This enables
> us to transfer data, ping etc. between active VME-modules using the
> VME-bus. Very useful.
>
> Well, the problem we will surely run into is: will the driver work as fine as
> the old one if we only recreate the initialization functions working with the
> new kernel function set (e.g. wait_event_interruptible instead of
> interruptible_sleep_on etc.), copy the essential functions from the old
> driver
> to the new one and alter them a little to work with the new kernel functions?
> Or is there anything else to put an eye on?
>
>
> Thankx a lot
>
> kind regards
> Hendrik

I had a lot of 2.4.x drivers I had to convert to 2.6.x. It is
possible to re-do the source code so that the two drivers will
compile and run on both versions. There have been several
important changes, but it's not too hard.

If your old driver is in good shape, I'd suggest you just
try to compile it using:

LD = ld
VER := $(shell uname -r)
TOP = /usr/src/linux-$(VER)/include
INC = -I$(TOP) -I/usr/src/linux-$(VER)/include/asm/mach-default
DEF = -D__KERNEL__ -DMODULE -DCONFIG_SMP
OPT = -fomit-frame-pointer -pipe -nostartfiles -Wstrict-prototypes \
       -fno-strict-aliasing
CC = gcc -Wall -O2 -I. $(INC) $(DEF) $(OPT)

... for the Makefile $(CC). This will not get you a module type
of module.ko, that's another step that uses the new kernel build
procedure (takes 60 seconds to modify your Makefile to do the
build).  The important thing it to get everything to compile
first. Any code that uses "#include <myfile.h>" where myfile
is in the local directory, needs to be changed to "myfile.h"
because the kernel build procedure doesn't propagate -I. for
include search paths.

Note the additional search path, above....

When you encounter an error, check with the new drivers in
the kernel to see what the new parameters are.

(1) ISR now takes a return value.
(2) mmap() is slightly different, requires additional parameter.
(3) MOD_INC/MOD_DEC  macros go away.
(4) Some PCI stuff, slightly different, need to check some return values
     even when it's implicit.
(5) struct file_operations has new member(s) first is 'owner',
     use macro THIS_MODULE.
(6) Kernel daemon start code is slightly different, daemonize() takes
     parameters and does most everything.
(7) Timer-queues slightly different, macros provided (easier).
(N) A few other kinks. I would guess that if the previous module
     was written properly, it would take less than an hour to
     update it.

FYI, I also used the Tundra chip for some VXI stuff. It
requires you to select an area in memory with no RAM for its
address area so its not very straight-forward. If your
previous stuff worked okay, you won't have problems with
the new kernels because they, too, allow you to hard-code
address-space that the kernel isn't using. You need to
make sure that there is such address-space available, i.e.,
you can't use 4 gigs (or more) of RAM!

Cheers,
Dick Johnson
Penguin : Linux version 2.6.9 on an i686 machine (5537.79 BogoMips).
  Notice : All mail here is now cached for review by John Ashcroft.
                  98.36% of all statistics are fiction.

Re: IP Layer on VME-Bus

[Gabriel Paubert]

On Wed, Nov 03, 2004 at 02:45:53PM +0100, H. Wiese wrote:
> Hello,
> 
> we develop a driver which enables us to use an ip layer on top of the vme-bus
> technology. Now we got some problems with coding the driver. We already have
> an old version of this driver (called "dpn") which works well but has no use
> for us anymore since we upgraded our system from kernel 2.2.14 to 2.6.7. So
> now we have to create a new driver.
> 
> The old driver established the ip layer by accessing the dual port ram of
> the VME bus, which is based on a Tundra Universe II Chipset. This enables
> us to transfer data, ping etc. between active VME-modules using the
> VME-bus. Very useful.

Which Universe driver did you use? 

There are several floating around, mine among them. I plan to port 
it to 2.6, time permitting but I'm a bit worried by the size of the 
kernel these days. I have to run diskless systems with 16MB of RAM, 
my 2.2 kernels are about 800kB while the 2.6 kernels on my Mac are 
in the 5MB or more range. Even after removing USB, ext3 and a few 
other things, the 2.6.x kernel will be at least twice the size of 
the 2.2 series it seems.

With my Universe driver or anything derived from it, the thing to 
watch out for is the PCI memory space allocation, 2.2 simply did 
not have the support (it mostly used the thing as the BIOS/firmware
had configures it) and the Universe is a PCI mmio space hog with
base registers outside the standard PCI header space (there are 
valid reasons for both of these characteristics). 

> Well, the problem we will surely run into is: will the driver work as fine as
> the old one if we only recreate the initialization functions working with the
> new kernel function set (e.g. wait_event_interruptible instead of
> interruptible_sleep_on etc.), copy the essential functions from the old
> driver
> to the new one and alter them a little to work with the new kernel functions?

I'm already using wait_event_ and friends in my 2.2 drivers,
you should select a better example ;-)

	Regards,
	Gabriel