Linux VME driver issues

[Jerry]

So I got the stuff to put together a nice displacement measuring interferometer system. The cards are VME cards, all in all they are pretty easy to deal with. Read a register it takes a sample of the position register in the card and it dumps it out.

So I got a VME rack and a could VME based single board computers to try to put something together. The SBCs have what is called a Universe chip, it is a PCI-VME bridge. Not a whole lot of drivers out there for this guy, there is one guy that makes a driver for windows and then there is VMELinux which is a linux driver module for the Universe chip. Two versions out there, this real old version for 2.2 and 2.4 kernels : http://www.vmelinux.org

And this updated version of it that runs on 2.6.x and 3.x kernels. https://github.com/mgmarino/VMELinux

Im trying to use the second one, using the first would mean trying to set up Red Hat 5 or Fedora 1. So I went with fedora 15 installing a command line only version. After a few false starts and finding and fixing a bug in a perl script, I got the driver to install. Well, mostly. I can see it if I do a cat /proc/iomem but it is not showing up in /proc itself, there should be a /proc/universe entry there and there is not.

At boot it seems to be loading according to dmesg:

Code: Select all

[   25.694276] universe: Tundra Universe II PCI-VME Driver 2.1 2015May12
[   25.694282] universe: Copyright 2008, Michael G. Marino
[   25.694287] universe: Device files major number: 250
[   25.694298] universe: Universe device found.
[   25.694314] pci 0000:02:03.0: found PCI INT A -> IRQ 9
[   25.694323] pci 0000:02:03.0: sharing IRQ 9 with 0000:00:02.0
[   25.694330] pci 0000:02:03.0: sharing IRQ 9 with 0000:00:1d.0
[   25.694349] universe: Universe device enabled.
[   25.694381] universe: Assigned irq 9

There is also an directory in /sys/module as well as when I do a cat /proc/devices

Anyone? This is my first real project having to deal with the deeper parts of linux and I am pretty lost.

If someone wants to SSH in and play around I can set that up.

[Doug Coulter]

Not a fedora guy, but I know a few and will look into it. dmesg is likely not your only source of info here, and you might be able to "hook" the loading process to get more info. /proc can be a little different between fedora and debian (which is what I've got everywhere here), and of course, old vs new. A couple of systems here don't have a /proc universe at all (all the ones I've checked). May not be the issue, or may be something RedHat-specific there.
Things like this don't show up in debian's GUI process monitor normally either, even if you know they are there.

You didn't say what is actually failing, just that you didn't see some stuff you expected to see....

Can you elaborate on that and the perl bug? (perl is something I DO pretty well and it might be a clue)

Doing things like talking straight to ram (or mapped, like iomem) is one of the things that's been changing rapidly as a result of hardening linux generally...
Various "doesn't exist" or "can't see if you aren't root" and so on fixes have been going in like mad....could be all sorts of stuff. I see you're running older versions, which is probably better in this regard.

Can you find an app - with source - that talks to iomem for any reason at all so we can see the mechanism and what calls are used?

[Jerry]

Yeah, linux is all a mess to me.

The perl bug. There is a script that at install looks for the largest chunk of iomem available and where it is and then requests that chunk in a 256mb aligned chunk. It was reporting to the installer that the chunk started at 0x50000000 and was 0x90000000 big. The address was correct but the size was 0x10000000 too big and was trying to install over already requested memory in the 0xD0000000 area. What was happening is the big contiguous block was starting after 0x400003ff and the next used space started at 0xd8000000. So yes, there is 0x90000000 available but there is only 0x80000000 available when you adjust for block starting in 0x10000000 whole increments.

So I added a few lines code to take in account of an uneven starting address. Sadly nothing too exciting.

Im not using any gui here, strict command line. Once this thing is running and reading off the VME it will dump into the network to a tiny XP box where I can run labview to do the math and other stuff.

Ill get some VME cards installed in the crate and try talking to them. Maybe it is just a minor issue and it is actually working. I know these cards have a user addressable LED on the front that I should be able to set from the VME bus. Bit 0 at address offset 0x08.

[Doug Coulter]

On a little checking I note GCC has undergone MAJOR change since....and yeah, there have been some backward compatibility issues along the way.

I guess we all approach these kinds of things a little differently. While I'm pretty strong on the command line, I still like guis if for no other reason than to have a few terminals at a time. Since I do write code in various languages (perl included), I'll often output a debug stream - by whatever means, so I can tail it on one terminal while doing things to prod the thing I'm debugging on another, stuff like that, especially when I'm working with something I'm not real familiar with. I'll write "diagnostics" which just test my understanding of the api - often call by call, this way. And yes, a led I can blink (and hang a scope probe on too!) is extremely useful once I get it to blink at all...the other stuff is how I get there.

Remember, someone else had to debug this once. There's probably a whole family of helpful system call stuff. This might or might not be a "one weird trick" kinda thing, you might have to step by step the sucker.

Auto updating GUI stuff - it's handy. Even if you're not going to use it in production. This would be pretty much just like what I do with raspberry pies (never did figure out a good plural for those). I use a GUI to put the server stuff together, it's a great help in debug (and discoverability), then...well, something else does the eventual heavy lifting and real time stuff as required, and the gui might be there - but nothing's using it and it doesn't seem to load things up much. But man, that VNC (I use tightvnc) is killer handy sometimes. I used it just tonight to debug a temporary failure in a remote esp8266 that fed a pi database that something else plots and web serves for me (my house weather data in this case). Discoverability is a big deal for me sometimes - menus, realtime file watchers, stuff like that.
Much harder to accomplish over a single terminal. Maybe I'm spoiled.

I don't think my old book on linux hardware drivers is still relevant. I used to do windows...yuck (double), especially memory mapping between physical, kernal, and userspace (all 3 were different in the 9x series). I don't think this is that bad, but basically I don't have enough to go on to really help you here - like "when you diddle the iomem, do you get an error, and if so, what error" kind of clue. I just haven't worked in that family of system calls thus far, no need yet.

But since that stuff comes as source you can build, you could put printf or == statements in it and at least have them say "I got here and I see whatever" till you get it all working. (if not printf, pipe, write a file, send stuff to system logs, whatever, same idea).

The perl bug is interesting, Seems like someone must have coded/tested on a single system and quit when it worked rather than really understanding it all. "Coding till it stops crashing, while at the screen" is usually gives kinda low grade results.