On 23/07/14 03:09, Maurice Moss wrote:
Hi Martyn,
Thanks for your patience with me. I have a couple of questions for you:
0. I put the SBC with the right settings for Geographical addressing.
I did 2 tests by setting the board in each of the 2 slots available on
my rack and the geo address was detected as 0 in both the cases. This
means my backplane isn't working or that my SBC isn't talking to the
backplane.
What settings did you apply to "set" geographical addressing? Is this
the drivers or something board specific?
1. Is there a way I can test whether the PCI bridge is working?
I assume you mean whether the PCI bridges are passing the PCI address
ranges used by the VME windows through to the device?
It think "lspci -v" will show you what ranges the bridges have, you will
probably need to stick some debug into vme_tsi148.c to get the pci_base
address as allocated in tsi148_master_set().
This can be very board dependant, so I'm afraid I can't help much here.
2. I don't understand what should be the exact vme base address of my
slave board. I am now using VDIS8004 set in slot 2,
(http://www.ifh.de/~wischnew/amanda/daq/ces_8004_v10_.pdf) set to VME
short A16 (The static rotatory switches set to 2 and 2). Based on
this my address would be 0x2200? Any clarification or pointing me in
the right direction would be sincerely appreciated :-/
There are limitations to the granularity of windows bases and lengths.
This is especially acute when using the A16 address space.
To debug this, try mapping the entirety of the A16 address space using
master_set. Then when calling read, read from offset 0x2200.
3. When I do reads with what I believe is the correct address, I get
back '0xff' characters all the time, and if I do it frequently enough
I manage to crash the computer (with no logs on the dmesg, and reboot
needed with a forced fsck). I am now trying to probe the kernel
module adding print statements, and trying to build it out of tree.
There was a bug when err_chk was set a while back, if you are running an
older kernel you may be hitting that. It stores errors, but in some
situations doesn't read them and clear them in time leading to memory
exhaustion...
Cheers,
Maurice
PS: Here is what I get when I do an 'lspci -v':
03:00.0 PCI bridge: PLX Technology, Inc. PEX 8114 PCI
Express-to-PCI/PCI-X Bridge (rev bd) (prog-if 00 [Normal decode])
Physical Slot: 0
Flags: bus master, fast devsel, latency 0
Memory at d4000000 (32-bit, non-prefetchable) [size=8K]
Bus: primary=03, secondary=04, subordinate=04, sec-latency=64
Memory behind bridge: d0000000-d3ffffff
Capabilities: <access denied>
04:04.0 Bridge: Tundra Semiconductor Corp. Tsi148 [Tempe] (rev 01)
Subsystem: Tundra Semiconductor Corp. Device 0000
Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 16
Memory at d0000000 (64-bit, non-prefetchable) [size=4K]
Capabilities: <access denied>
Kernel driver in use: vme_tsi148
The reads don't occur through the PCI bars (nasty), so you will need to
find out what PCI addresses the windows are being mapped to and confirm
they are in the d0000000-d3ffffff window. Without knowing much more
about your system (and I don't think you've even told me what SBC you
are using) there's a limit to how much I can help I'm afraid.
Hope that helps,
Martyn
On Wed, Jul 16, 2014 at 12:47 AM, Martyn Welch <martyn.welch@xxxxxx> wrote:
On 14/07/14 19:29, Maurice Moss wrote:
Hi all,
I have updated my Linux Kernel to the latest. I am on Debian 64bit
3.15.5. I issue the following Kernel command line, and the vme_user
module seems to load correctly, however the vme bus is neither mounted
on /dev nor /proc.
Just to make sure, you're looking under /dev/bus/vme?
I was earlier using a 3.2 debian 32bit and managed to mount the vme
bus by following the exact same procedure of rebuilding the kernel
with vme_user module. Any help is appreciated. Here is what I see on
dmesg.
[ 0.000000] Kernel command line:
BOOT_IMAGE=/boot/vmlinuz-3.15.5-vme
root=UUID=4cdc2e84-9fbc-471c-9eb4-fde8f0b1ce96 ro vme_user.bus=0
vme_tsi148.err_chk=1 quiet
[ 1.754278] vme_user: VME User Space Access Driver
[ 1.754695] vme_tsi148 0000:04:04.0: Board is the VME system controller
[ 1.754700] vme_tsi148 0000:04:04.0: VME geographical address is 0
[ 1.754704] vme_tsi148 0000:04:04.0: VME Write and flush and error
check is enabled
[ 1.754942] vme_tsi148 0000:04:04.0: CR/CSR Offset: 0
[ 1.754948] vme_tsi148 0000:04:04.0: Enabling CR/CSR space
Cheers!
It's unfortunately going to take me a while to get everything together to
take a look, some of my old installs I've been eeking along for a while to
do adhoc VME tests are now broken :-(
Martyn
On Thu, Jul 3, 2014 at 8:18 AM, Maurice Moss <eightplusclub@xxxxxxxxx>
wrote:
Martyn,
OK. I feel like I am not clear. The kernel command line has a space,
but the line here in the email doesn't (I don't know how that
happened). I am still stuck with the same issue.
Sorry for all the confusion
On Thu, Jul 3, 2014 at 8:15 AM, Maurice Moss <eightplusclub@xxxxxxxxx>
wrote:
Yes, copy and paste issue, I had double checked that right after I
sent you the mail. Sorry!!
On Thu, Jul 3, 2014 at 3:47 AM, Martyn Welch <martyn.welch@xxxxxx>
wrote:
On 03/07/14 00:47, Maurice Moss wrote:
I upgraded to linux kernel 3.14.9 (on Fedora). Re-compiled the kernel
with the vme support etc. I now get the below in my log, and don't
see any vme related files in /dev !!
[ 0.000000] Kernel command line: BOOT_IMAGE=/vmlinuz-3.14.9
root=UUID=aee6e594-4be8-46d4-abe6-7c054ef239b0 ro
vconsole.font=latarcyrheb-sun16 vme_user.bus=0vme_tsi148.err_chk=1
rhgb quiet
Unless this is a copy and paste issue, you seem to be missing a space
between "vme_user.bus=0" and "vme_tsi148.err_chk=1".
Martyn
--
Martyn Welch (Lead Software Engineer) | Registered in England and
Wales
GE Intelligent Platforms | (3828642) at 100 Barbirolli
Square
T +44(0)1327322748 | Manchester, M2 3AB
E martyn.welch@xxxxxx | VAT:GB 927559189
--
Martyn Welch (Lead Software Engineer) | Registered in England and Wales
GE Intelligent Platforms | (3828642) at 100 Barbirolli Square
T +44(0)1327322748 | Manchester, M2 3AB
E martyn.welch@xxxxxx | VAT:GB 927559189
--
Martyn Welch (Lead Software Engineer) | Registered in England and Wales
GE Intelligent Platforms | (3828642) at 100 Barbirolli Square
T +44(0)1327322748 | Manchester, M2 3AB
E martyn.welch@xxxxxx | VAT:GB 927559189
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
