Re: XVME 6300 with TSI148 bridge on 64 bit Debian (Linux 3.2.57) vme_user issue
Hi Martyn,
Any update on this from your side?
Cheers!
On Mon, Nov 10, 2014 at 10:22 AM, Maurice Moss eightplusc...@gmail.com wrote:
Hi Martyn,
Thanks for your reply. I have pasted the code below. It is very much
similar to your test code from the forum.
Thanks!
#define _XOPEN_SOURCE 500
#define u32 unsigned int
#include stdio.h
#include stdlib.h
#include sys/ioctl.h
#include sys/types.h
#include sys/stat.h
#include fcntl.h
#include unistd.h
#include vme_user.h
int main(int argc, char *argv[])
{
int fd;
int i;
int retval;
int readSize = 2;
unsigned char data[readSize];
struct vme_master master;
printf(Simple VME User Module Test\n);
fd = open(/dev/bus/vme/m0, O_RDONLY);
if (fd == -1) {
perror(ERROR: Opening window device file);
return 1;
}
printf (opened the file\n);
master.enable = 1;
//master.vme_addr = 0x114000;
master.vme_addr = 0x114000;
master.size = 0x1;
master.aspace = 0x2; // VME_A24
master.cycle = 0x2000 | 0x8000;// user/data access
master.dwidth = 0x2; // 16 bit word access
retval = ioctl(fd, VME_SET_MASTER, master);
if (retval != 0) {
printf(retval=%d\n, retval);
perror(ERROR: Failed to configure window);
return 1;
}
printf (set the master\n);
/*
* Reading first 512 bytes
*/
for (i=0; ireadSize; i++) {
data[i] = 0;
}
retval = pread(fd, data, readSize, 0x03c);
if (retval readSize) {
printf(WARNING: Only read %d bytes, retval);
}
for(i=0; iretval; i++) {
if (i % 8 == 0) {
printf(\n%4.4x: , i);
}
printf(%2.2x , data[i]);
}
printf(\n);
close(fd);
return 0;
}
On Mon, Nov 10, 2014 at 4:07 AM, Welch, Martyn (GE Intelligent
Platforms) martyn.we...@ge.com wrote:
Hi Maurice,
Would you be able to point to a complete piece of test code that exhibits
this failure?
Martyn Welch
Lead Software Engineer
GE Intelligent Platforms
Embedded Systems
T +44 (0) 1327 322748
F +44 (0) 1327 322817
E martyn.we...@ge.com
Tove Valley Business Park
Towcester, Northants, NN12 6PF, United Kingdom
GE Intelligent Platforms Ltd
GE imagination at work
GE Intelligent Platforms Ltd, registered in England and Wales (3828642) at
100 Barbirolli Square, Manchester, M2 3AB, VAT GB 927 5591 89
-Original Message-
From: Maurice Moss [mailto:eightplusc...@gmail.com]
Sent: 08 November 2014 00:33
To: Welch, Martyn (GE Intelligent Platforms)
Cc: Manohar Vanga; dan.carpen...@oracle.com; driverdev-
de...@linuxdriverproject.org
Subject: Re: XVME 6300 with TSI148 bridge on 64 bit Debian (Linux 3.2.57)
vme_user issue
Hi Manohar/Dan,
Any idea regarding this?
Cheers,
Maurice
On Mon, Nov 3, 2014 at 5:25 PM, Maurice Moss eightplusc...@gmail.com
wrote:
Hi Martyn,
Thanks for your help from previous emails. I managed to talk to my
board using a VME-USB board. Now I am back to working with an SBC, and
I have a different setup this time around, let me describe it:
1. SBC in slot 0 of a VME64 chassis (with 2 slots), and the bottom one
being a slot for an SBC. The SBC is has a Universe-II and when I load
the kernel module manually, everything seems fine, and I see this in
dmesg:
[ 76.192738] vme_ca91cx42 :02:04.0: enabling device (0140 - 0143)
[ 76.192893] vme_ca91cx42 :02:04.0: Board is the VME system
controller
[ 76.192902] vme_ca91cx42 :02:04.0: Slot ID is 0
[ 76.192907] vme_ca91cx42 :02:04.0: CR/CSR Offset: 0
[ 76.192911] vme_ca91cx42 :02:04.0: Slot number is unset, not
configuring CR/CSR space
[ 76.195956] vme_ca91cx42 :02:04.0: CR/CSR configuration failed.
I don't intend to use CR/CSR feature. The linux kernel I am running
is 3.13, the board is essentially this:
http://www.onestopsystems.com/documents/OSS-PCIe-KIT-6400.pdf
2. Now I would like to talk to a passive Slave board in slot 1 (I am
not sure about this numbering, basically the board in the other slot).
This slave board essentially talks only A24 and D16 in
user/super/data. It's address space internally begins at 0x114000. In
my test code, I essentially have the following:
master.enable = 1;
//master.vme_addr = 0x114000;
master.vme_addr = 0x114000;
master.size = 0x1;
master.aspace = 0x2; // VME_A24
master.cycle = 0x2000 | 0x8000;// user/data access
master.dwidth = 0x2; // 16 bit word access
retval = ioctl(fd, VME_SET_MASTER, master);
The call doesn't fail, and when I make a pread, all I get are 0xff s
Re: XVME 6300 with TSI148 bridge on 64 bit Debian (Linux 3.2.57) vme_user issue
Hi Martyn,
Thanks for your reply. I have pasted the code below. It is very much
similar to your test code from the forum.
Thanks!
#define _XOPEN_SOURCE 500
#define u32 unsigned int
#include stdio.h
#include stdlib.h
#include sys/ioctl.h
#include sys/types.h
#include sys/stat.h
#include fcntl.h
#include unistd.h
#include vme_user.h
int main(int argc, char *argv[])
{
int fd;
int i;
int retval;
int readSize = 2;
unsigned char data[readSize];
struct vme_master master;
printf(Simple VME User Module Test\n);
fd = open(/dev/bus/vme/m0, O_RDONLY);
if (fd == -1) {
perror(ERROR: Opening window device file);
return 1;
}
printf (opened the file\n);
master.enable = 1;
//master.vme_addr = 0x114000;
master.vme_addr = 0x114000;
master.size = 0x1;
master.aspace = 0x2; // VME_A24
master.cycle = 0x2000 | 0x8000;// user/data access
master.dwidth = 0x2; // 16 bit word access
retval = ioctl(fd, VME_SET_MASTER, master);
if (retval != 0) {
printf(retval=%d\n, retval);
perror(ERROR: Failed to configure window);
return 1;
}
printf (set the master\n);
/*
* Reading first 512 bytes
*/
for (i=0; ireadSize; i++) {
data[i] = 0;
}
retval = pread(fd, data, readSize, 0x03c);
if (retval readSize) {
printf(WARNING: Only read %d bytes, retval);
}
for(i=0; iretval; i++) {
if (i % 8 == 0) {
printf(\n%4.4x: , i);
}
printf(%2.2x , data[i]);
}
printf(\n);
close(fd);
return 0;
}
On Mon, Nov 10, 2014 at 4:07 AM, Welch, Martyn (GE Intelligent
Platforms) martyn.we...@ge.com wrote:
Hi Maurice,
Would you be able to point to a complete piece of test code that exhibits
this failure?
Martyn Welch
Lead Software Engineer
GE Intelligent Platforms
Embedded Systems
T +44 (0) 1327 322748
F +44 (0) 1327 322817
E martyn.we...@ge.com
Tove Valley Business Park
Towcester, Northants, NN12 6PF, United Kingdom
GE Intelligent Platforms Ltd
GE imagination at work
GE Intelligent Platforms Ltd, registered in England and Wales (3828642) at
100 Barbirolli Square, Manchester, M2 3AB, VAT GB 927 5591 89
-Original Message-
From: Maurice Moss [mailto:eightplusc...@gmail.com]
Sent: 08 November 2014 00:33
To: Welch, Martyn (GE Intelligent Platforms)
Cc: Manohar Vanga; dan.carpen...@oracle.com; driverdev-
de...@linuxdriverproject.org
Subject: Re: XVME 6300 with TSI148 bridge on 64 bit Debian (Linux 3.2.57)
vme_user issue
Hi Manohar/Dan,
Any idea regarding this?
Cheers,
Maurice
On Mon, Nov 3, 2014 at 5:25 PM, Maurice Moss eightplusc...@gmail.com
wrote:
Hi Martyn,
Thanks for your help from previous emails. I managed to talk to my
board using a VME-USB board. Now I am back to working with an SBC, and
I have a different setup this time around, let me describe it:
1. SBC in slot 0 of a VME64 chassis (with 2 slots), and the bottom one
being a slot for an SBC. The SBC is has a Universe-II and when I load
the kernel module manually, everything seems fine, and I see this in
dmesg:
[ 76.192738] vme_ca91cx42 :02:04.0: enabling device (0140 - 0143)
[ 76.192893] vme_ca91cx42 :02:04.0: Board is the VME system
controller
[ 76.192902] vme_ca91cx42 :02:04.0: Slot ID is 0
[ 76.192907] vme_ca91cx42 :02:04.0: CR/CSR Offset: 0
[ 76.192911] vme_ca91cx42 :02:04.0: Slot number is unset, not
configuring CR/CSR space
[ 76.195956] vme_ca91cx42 :02:04.0: CR/CSR configuration failed.
I don't intend to use CR/CSR feature. The linux kernel I am running
is 3.13, the board is essentially this:
http://www.onestopsystems.com/documents/OSS-PCIe-KIT-6400.pdf
2. Now I would like to talk to a passive Slave board in slot 1 (I am
not sure about this numbering, basically the board in the other slot).
This slave board essentially talks only A24 and D16 in
user/super/data. It's address space internally begins at 0x114000. In
my test code, I essentially have the following:
master.enable = 1;
//master.vme_addr = 0x114000;
master.vme_addr = 0x114000;
master.size = 0x1;
master.aspace = 0x2; // VME_A24
master.cycle = 0x2000 | 0x8000;// user/data access
master.dwidth = 0x2; // 16 bit word access
retval = ioctl(fd, VME_SET_MASTER, master);
The call doesn't fail, and when I make a pread, all I get are 0xff s
on every byte.
I feel like I just can't seem to get the vme_addr to point in the
right direction. I know it's not the slave board, as I have verified
that it works with the VME-to-USB.
In my
Re: XVME 6300 with TSI148 bridge on 64 bit Debian (Linux 3.2.57) vme_user issue
Hi Manohar/Dan, Any idea regarding this? Cheers, Maurice On Mon, Nov 3, 2014 at 5:25 PM, Maurice Moss eightplusc...@gmail.com wrote: Hi Martyn, Thanks for your help from previous emails. I managed to talk to my board using a VME-USB board. Now I am back to working with an SBC, and I have a different setup this time around, let me describe it: 1. SBC in slot 0 of a VME64 chassis (with 2 slots), and the bottom one being a slot for an SBC. The SBC is has a Universe-II and when I load the kernel module manually, everything seems fine, and I see this in dmesg: [ 76.192738] vme_ca91cx42 :02:04.0: enabling device (0140 - 0143) [ 76.192893] vme_ca91cx42 :02:04.0: Board is the VME system controller [ 76.192902] vme_ca91cx42 :02:04.0: Slot ID is 0 [ 76.192907] vme_ca91cx42 :02:04.0: CR/CSR Offset: 0 [ 76.192911] vme_ca91cx42 :02:04.0: Slot number is unset, not configuring CR/CSR space [ 76.195956] vme_ca91cx42 :02:04.0: CR/CSR configuration failed. I don't intend to use CR/CSR feature. The linux kernel I am running is 3.13, the board is essentially this: http://www.onestopsystems.com/documents/OSS-PCIe-KIT-6400.pdf 2. Now I would like to talk to a passive Slave board in slot 1 (I am not sure about this numbering, basically the board in the other slot). This slave board essentially talks only A24 and D16 in user/super/data. It's address space internally begins at 0x114000. In my test code, I essentially have the following: master.enable = 1; //master.vme_addr = 0x114000; master.vme_addr = 0x114000; master.size = 0x1; master.aspace = 0x2; // VME_A24 master.cycle = 0x2000 | 0x8000;// user/data access master.dwidth = 0x2; // 16 bit word access retval = ioctl(fd, VME_SET_MASTER, master); The call doesn't fail, and when I make a pread, all I get are 0xff s on every byte. I feel like I just can't seem to get the vme_addr to point in the right direction. I know it's not the slave board, as I have verified that it works with the VME-to-USB. In my mind, I have to set the SBC as a VME master and make a read at A24 address. However, in vme_user.c I notice that the master resource is allocated as A32. Which is why I just can't seem to get the whole addressing schema right! Here is my lspci -v 02:04.0 Bridge: Tundra Semiconductor Corp. CA91C042 [Universe] (rev 02) Flags: medium devsel, IRQ 16 Memory at f7d0 (32-bit, non-prefetchable) [size=4K] I/O ports at e000 [size=4K] Kernel driver in use: vme_ca91cx42 08:00.0 PCI bridge: Tundra Semiconductor Corp. Device 8113 (rev 01) (prog-if 01 [Subtractive decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=08, secondary=09, subordinate=09, sec-latency=64 Memory behind bridge: f700-f78f Prefetchable memory behind bridge: f600-f6ff Capabilities: access denied Any help is as usual thoroughly appreciated. And in addition thanks for all your help already! Cheers, Maurice On Thu, Jul 24, 2014 at 1:45 AM, Martyn Welch martyn.we...@ge.com wrote: 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
Re: XVME 6300 with TSI148 bridge on 64 bit Debian (Linux 3.2.57) vme_user issue
Hi Martyn, Thanks for your help from previous emails. I managed to talk to my board using a VME-USB board. Now I am back to working with an SBC, and I have a different setup this time around, let me describe it: 1. SBC in slot 0 of a VME64 chassis (with 2 slots), and the bottom one being a slot for an SBC. The SBC is has a Universe-II and when I load the kernel module manually, everything seems fine, and I see this in dmesg: [ 76.192738] vme_ca91cx42 :02:04.0: enabling device (0140 - 0143) [ 76.192893] vme_ca91cx42 :02:04.0: Board is the VME system controller [ 76.192902] vme_ca91cx42 :02:04.0: Slot ID is 0 [ 76.192907] vme_ca91cx42 :02:04.0: CR/CSR Offset: 0 [ 76.192911] vme_ca91cx42 :02:04.0: Slot number is unset, not configuring CR/CSR space [ 76.195956] vme_ca91cx42 :02:04.0: CR/CSR configuration failed. I don't intend to use CR/CSR feature. The linux kernel I am running is 3.13, the board is essentially this: http://www.onestopsystems.com/documents/OSS-PCIe-KIT-6400.pdf 2. Now I would like to talk to a passive Slave board in slot 1 (I am not sure about this numbering, basically the board in the other slot). This slave board essentially talks only A24 and D16 in user/super/data. It's address space internally begins at 0x114000. In my test code, I essentially have the following: master.enable = 1; //master.vme_addr = 0x114000; master.vme_addr = 0x114000; master.size = 0x1; master.aspace = 0x2; // VME_A24 master.cycle = 0x2000 | 0x8000;// user/data access master.dwidth = 0x2; // 16 bit word access retval = ioctl(fd, VME_SET_MASTER, master); The call doesn't fail, and when I make a pread, all I get are 0xff s on every byte. I feel like I just can't seem to get the vme_addr to point in the right direction. I know it's not the slave board, as I have verified that it works with the VME-to-USB. In my mind, I have to set the SBC as a VME master and make a read at A24 address. However, in vme_user.c I notice that the master resource is allocated as A32. Which is why I just can't seem to get the whole addressing schema right! Here is my lspci -v 02:04.0 Bridge: Tundra Semiconductor Corp. CA91C042 [Universe] (rev 02) Flags: medium devsel, IRQ 16 Memory at f7d0 (32-bit, non-prefetchable) [size=4K] I/O ports at e000 [size=4K] Kernel driver in use: vme_ca91cx42 08:00.0 PCI bridge: Tundra Semiconductor Corp. Device 8113 (rev 01) (prog-if 01 [Subtractive decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=08, secondary=09, subordinate=09, sec-latency=64 Memory behind bridge: f700-f78f Prefetchable memory behind bridge: f600-f6ff Capabilities: access denied Any help is as usual thoroughly appreciated. And in addition thanks for all your help already! Cheers, Maurice On Thu, Jul 24, 2014 at 1:45 AM, Martyn Welch martyn.we...@ge.com wrote: 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
Re: XVME 6300 with TSI148 bridge on 64 bit Debian (Linux 3.2.57) vme_user issue
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 d400 (32-bit, non-prefetchable) [size=8K] Bus: primary=03, secondary=04, subordinate=04, sec-latency=64 Memory behind bridge: d000-d3ff Capabilities: access denied 04:04.0 Bridge: Tundra Semiconductor Corp. Tsi148 [Tempe] (rev 01) Subsystem: Tundra Semiconductor Corp. Device Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 16 Memory at d000 (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 d000-d3ff 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.we...@ge.com 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.00] 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 :04:04.0: Board is the VME system controller [1.754700] vme_tsi148 :04:04.0: VME geographical address is 0 [1.754704] vme_tsi148 :04:04.0: VME Write and flush and error check is enabled [1.754942] vme_tsi148 :04:04.0: CR/CSR Offset: 0 [1.754948] vme_tsi148 :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 eightplusc...@gmail.com wrote: Martyn, OK. I feel like I am not clear. The kernel command line has a space,
Re: XVME 6300 with TSI148 bridge on 64 bit Debian (Linux 3.2.57) vme_user issue
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. 1. Is there a way I can test whether the PCI bridge is working? 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 :-/ 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. 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 d400 (32-bit, non-prefetchable) [size=8K] Bus: primary=03, secondary=04, subordinate=04, sec-latency=64 Memory behind bridge: d000-d3ff Capabilities: access denied 04:04.0 Bridge: Tundra Semiconductor Corp. Tsi148 [Tempe] (rev 01) Subsystem: Tundra Semiconductor Corp. Device Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 16 Memory at d000 (64-bit, non-prefetchable) [size=4K] Capabilities: access denied Kernel driver in use: vme_tsi148 On Wed, Jul 16, 2014 at 12:47 AM, Martyn Welch martyn.we...@ge.com 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.00] 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 :04:04.0: Board is the VME system controller [1.754700] vme_tsi148 :04:04.0: VME geographical address is 0 [1.754704] vme_tsi148 :04:04.0: VME Write and flush and error check is enabled [1.754942] vme_tsi148 :04:04.0: CR/CSR Offset: 0 [1.754948] vme_tsi148 :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 eightplusc...@gmail.com 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 eightplusc...@gmail.com 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.we...@ge.com 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.00] 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.we...@ge.com | 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
Re: XVME 6300 with TSI148 bridge on 64 bit Debian (Linux 3.2.57) vme_user issue
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.00] 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 :04:04.0: Board is the VME system controller [1.754700] vme_tsi148 :04:04.0: VME geographical address is 0 [1.754704] vme_tsi148 :04:04.0: VME Write and flush and error check is enabled [1.754942] vme_tsi148 :04:04.0: CR/CSR Offset: 0 [1.754948] vme_tsi148 :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 eightplusc...@gmail.com 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 eightplusc...@gmail.com 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.we...@ge.com 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.00] 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.we...@ge.com | 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.we...@ge.com | VAT:GB 927559189 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: XVME 6300 with TSI148 bridge on 64 bit Debian (Linux 3.2.57) vme_user issue
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. 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.00] 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 :04:04.0: Board is the VME system controller [1.754700] vme_tsi148 :04:04.0: VME geographical address is 0 [1.754704] vme_tsi148 :04:04.0: VME Write and flush and error check is enabled [1.754942] vme_tsi148 :04:04.0: CR/CSR Offset: 0 [1.754948] vme_tsi148 :04:04.0: Enabling CR/CSR space Cheers! On Thu, Jul 3, 2014 at 8:18 AM, Maurice Moss eightplusc...@gmail.com 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 eightplusc...@gmail.com 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.we...@ge.com 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.00] 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.we...@ge.com | VAT:GB 927559189 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: XVME 6300 with TSI148 bridge on 64 bit Debian (Linux 3.2.57) vme_user issue
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.00] 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.we...@ge.com | VAT:GB 927559189 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: XVME 6300 with TSI148 bridge on 64 bit Debian (Linux 3.2.57) vme_user issue
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.we...@ge.com 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.00] 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.we...@ge.com | VAT:GB 927559189 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: XVME 6300 with TSI148 bridge on 64 bit Debian (Linux 3.2.57) vme_user issue
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 eightplusc...@gmail.com 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.we...@ge.com 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.00] 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.we...@ge.com | VAT:GB 927559189 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: XVME 6300 with TSI148 bridge on 64 bit Debian (Linux 3.2.57) vme_user issue
Hi Martyn,
Thanks a lot for your guidance. I am back working on vme and I am
trying it with a newer kernel, and I seem to have gone backwards!
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.00] 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
[1.879625] vme_user: VME User Space Access Driver
[1.879846] vme_tsi148 :04:04.0: Board is the VME system controller
[1.879849] vme_tsi148 :04:04.0: VME geographical address is 0
[1.879851] vme_tsi148 :04:04.0: VME Write and flush and error
check is enabled
[1.880240] vme_tsi148 :04:04.0: CR/CSR Offset: 0
[1.880244] vme_tsi148 :04:04.0: Enabling CR/CSR space
Any help is sincerely appreciated :)
Cheers!
On Tue, Jun 24, 2014 at 4:19 AM, Martyn Welch martyn.we...@ge.com wrote:
On 23/06/14 16:05, Maurice Moss wrote:
Hi All,
Thanks for your reply. I have been away the last few weeks.
Dan, I am using 64 bit Debian 3.2.57. So I am not using the latest
kernel. Would this be a problem?
That's probably quite old now. Depending on your hardware there may be
important fixes. There was certainly one to get the driver working on SBCs
with IOMMUs, though I'm afraid I don't know exactly which version that
landed in off the top of my head.
Martyn, I don't have a bus analyzer. I believe I have understood a
few more things about my setup, but I still manage to hang the bus. I
have the following questions for now:
1. Is there a way to find out if the tsi148 driver is working correctly?
Do you have a second SBC? It would probably be easier to prove out basic
accesses between 2 SBCs.
2. Addressing?! I am still not clear on the addressing scheme. From
the documentation of the slave (ZMI 4104 card) given it's set in slot
2 with Geographical Addressing enabled, the 24 bits of it's VME bus
address are:
A(23:20) - 'b [Board jumpers set to zero]
A(19:15) - 'b00010 [Geographical address set to 2, as the slave is in
slot 2]
A(14) - 'b0 [0 if Geo Addressing enabled]
AFAIK, this sets the base of the window to, 0x1. Am I correct to
assume this?
Might be worth checking that the backplane supports geographical addressing.
Can you put the SBC in the slot that the slave is usually in?
Assuming that the SBC is wired to support geographical addressing (and they
aren't always), the driver will print out the slot it detects it's in when
the driver is loaded. Make sure your not forcing the geographical address
via the kernel param! That'll hopefully confirm that the slots getting the
expected address.
Does the board expect user/data cycles?
The slave board responds to address modifier codes 0x39 (A24
non-privileged data access), and 0x3D (A24 supervisory data access),
hence I set:
master.cycle = 0x2000 | 0x8000; // user/data access
That sounds right.
Martyn
Cheers!
On Wed, Jun 11, 2014 at 10:36 AM, Martyn Welch martyn.we...@ge.com
wrote:
Hi Maurice,
On 04/06/14 22:43, Maurice Moss wrote:
Dear All,
I came across the link here and decided to write to you, as I am
facing a very similar problem:
http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2013-May/037941.html
With the above linux, I have recompiled the kernel and booting the
image with a vme_user.bus=0 vme_tsi148.geoid=1 vme_tsi148.err_chk=1
flags. I am just starting to get familiar with VME.
Using XVME 6300 (sitting in Slot 1), I am trying to access a ZMI 4100
board (in slot 2, only 2 slots on the chassis whose back plane
supports GA) via geographical addressing.
If the backplane supports geographical addressing, you don't need to set
geoid (unless your SBC doesn't support geoid that is).
The ZMI board (supports
only A24, D16/32, GA, NO CS/CSR). I pretty much have the same code as
mentioned in the thread, however all I read are 0xff's and my system
hangs every once in a while (needs hard reset). This makes debugging
very hard. I am trying to read valid registers at a given offset (in
this case 0x003C).
My master struct is setup as below and I hope you can help me with the
following questions:
master.enable = 1;
master.vme_addr = 0x1;
master.size = 0x1;
master.aspace = 2; // VME_A24
master.cycle = 0x2000 | 0x8000;// user/data access
master.dwidth = 2; // 16 bit word access
Is this offset 0x003C in the VME address space or 0x1003C? You have the
base
of the window set to 0x1.
Does the board expect user/data cycles?
0. I suspect my master struct is packed wrong.
struct vme_master {
int enable; /* State of Window */
unsigned long long vme_addr;/* Starting
Re: XVME 6300 with TSI148 bridge on 64 bit Debian (Linux 3.2.57) vme_user issue
On 23/06/14 16:05, Maurice Moss wrote:
Hi All,
Thanks for your reply. I have been away the last few weeks.
Dan, I am using 64 bit Debian 3.2.57. So I am not using the latest
kernel. Would this be a problem?
That's probably quite old now. Depending on your hardware there may be
important fixes. There was certainly one to get the driver working on
SBCs with IOMMUs, though I'm afraid I don't know exactly which version
that landed in off the top of my head.
Martyn, I don't have a bus analyzer. I believe I have understood a
few more things about my setup, but I still manage to hang the bus. I
have the following questions for now:
1. Is there a way to find out if the tsi148 driver is working correctly?
Do you have a second SBC? It would probably be easier to prove out basic
accesses between 2 SBCs.
2. Addressing?! I am still not clear on the addressing scheme. From
the documentation of the slave (ZMI 4104 card) given it's set in slot
2 with Geographical Addressing enabled, the 24 bits of it's VME bus
address are:
A(23:20) - 'b [Board jumpers set to zero]
A(19:15) - 'b00010 [Geographical address set to 2, as the slave is in slot 2]
A(14) - 'b0 [0 if Geo Addressing enabled]
AFAIK, this sets the base of the window to, 0x1. Am I correct to
assume this?
Might be worth checking that the backplane supports geographical
addressing. Can you put the SBC in the slot that the slave is usually in?
Assuming that the SBC is wired to support geographical addressing (and
they aren't always), the driver will print out the slot it detects it's
in when the driver is loaded. Make sure your not forcing the
geographical address via the kernel param! That'll hopefully confirm
that the slots getting the expected address.
Does the board expect user/data cycles?
The slave board responds to address modifier codes 0x39 (A24
non-privileged data access), and 0x3D (A24 supervisory data access),
hence I set:
master.cycle = 0x2000 | 0x8000; // user/data access
That sounds right.
Martyn
Cheers!
On Wed, Jun 11, 2014 at 10:36 AM, Martyn Welch martyn.we...@ge.com wrote:
Hi Maurice,
On 04/06/14 22:43, Maurice Moss wrote:
Dear All,
I came across the link here and decided to write to you, as I am
facing a very similar problem:
http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2013-May/037941.html
With the above linux, I have recompiled the kernel and booting the
image with a vme_user.bus=0 vme_tsi148.geoid=1 vme_tsi148.err_chk=1
flags. I am just starting to get familiar with VME.
Using XVME 6300 (sitting in Slot 1), I am trying to access a ZMI 4100
board (in slot 2, only 2 slots on the chassis whose back plane
supports GA) via geographical addressing.
If the backplane supports geographical addressing, you don't need to set
geoid (unless your SBC doesn't support geoid that is).
The ZMI board (supports
only A24, D16/32, GA, NO CS/CSR). I pretty much have the same code as
mentioned in the thread, however all I read are 0xff's and my system
hangs every once in a while (needs hard reset). This makes debugging
very hard. I am trying to read valid registers at a given offset (in
this case 0x003C).
My master struct is setup as below and I hope you can help me with the
following questions:
master.enable = 1;
master.vme_addr = 0x1;
master.size = 0x1;
master.aspace = 2; // VME_A24
master.cycle = 0x2000 | 0x8000;// user/data access
master.dwidth = 2; // 16 bit word access
Is this offset 0x003C in the VME address space or 0x1003C? You have the base
of the window set to 0x1.
Does the board expect user/data cycles?
0. I suspect my master struct is packed wrong.
struct vme_master {
int enable; /* State of Window */
unsigned long long vme_addr;/* Starting Address on the VMEbus
*/
unsigned long long size;/* Window Size */
vme_address_t aspace; /* Address Space */
vme_cycle_t cycle; /* Cycle properties */
vme_width_t dwidth; /* Maximum Data Width */
};
I'm not sure I follow.
1. I don't believe accessing 64k of the ZMI's VME address space is a
valid operation, could this be causing the bus to hang? Actually, I
have this doubt because I am unsure how exactly the master window is
setup.
Are you reading the whole of the 64k? From memory, the tsi148 has a minimum
window size of 64k, this should be fine as long as you don't read outside
the devices registers.
2. From the documentation of ZMI 4100, it is claimed that the board
supports VME64 and VME64X. However, I am not sure if master.cycle
bits for 2eVME need to be set or not?!
If you want to use the high speed block transfer modes, set them as required
in the cycle properties.
3. Is there away to prevent the bus from hanging by modifying tsi148
device code?
I'm not sure why it's hanging,
Re: XVME 6300 with TSI148 bridge on 64 bit Debian (Linux 3.2.57) vme_user issue
Hi All,
Thanks for your reply. I have been away the last few weeks.
Dan, I am using 64 bit Debian 3.2.57. So I am not using the latest
kernel. Would this be a problem?
Martyn, I don't have a bus analyzer. I believe I have understood a
few more things about my setup, but I still manage to hang the bus. I
have the following questions for now:
1. Is there a way to find out if the tsi148 driver is working correctly?
2. Addressing?! I am still not clear on the addressing scheme. From
the documentation of the slave (ZMI 4104 card) given it's set in slot
2 with Geographical Addressing enabled, the 24 bits of it's VME bus
address are:
A(23:20) - 'b [Board jumpers set to zero]
A(19:15) - 'b00010 [Geographical address set to 2, as the slave is in slot 2]
A(14) - 'b0 [0 if Geo Addressing enabled]
AFAIK, this sets the base of the window to, 0x1. Am I correct to
assume this?
Does the board expect user/data cycles?
The slave board responds to address modifier codes 0x39 (A24
non-privileged data access), and 0x3D (A24 supervisory data access),
hence I set:
master.cycle = 0x2000 | 0x8000; // user/data access
Cheers!
On Wed, Jun 11, 2014 at 10:36 AM, Martyn Welch martyn.we...@ge.com wrote:
Hi Maurice,
On 04/06/14 22:43, Maurice Moss wrote:
Dear All,
I came across the link here and decided to write to you, as I am
facing a very similar problem:
http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2013-May/037941.html
With the above linux, I have recompiled the kernel and booting the
image with a vme_user.bus=0 vme_tsi148.geoid=1 vme_tsi148.err_chk=1
flags. I am just starting to get familiar with VME.
Using XVME 6300 (sitting in Slot 1), I am trying to access a ZMI 4100
board (in slot 2, only 2 slots on the chassis whose back plane
supports GA) via geographical addressing.
If the backplane supports geographical addressing, you don't need to set
geoid (unless your SBC doesn't support geoid that is).
The ZMI board (supports
only A24, D16/32, GA, NO CS/CSR). I pretty much have the same code as
mentioned in the thread, however all I read are 0xff's and my system
hangs every once in a while (needs hard reset). This makes debugging
very hard. I am trying to read valid registers at a given offset (in
this case 0x003C).
My master struct is setup as below and I hope you can help me with the
following questions:
master.enable = 1;
master.vme_addr = 0x1;
master.size = 0x1;
master.aspace = 2; // VME_A24
master.cycle = 0x2000 | 0x8000;// user/data access
master.dwidth = 2; // 16 bit word access
Is this offset 0x003C in the VME address space or 0x1003C? You have the base
of the window set to 0x1.
Does the board expect user/data cycles?
0. I suspect my master struct is packed wrong.
struct vme_master {
int enable; /* State of Window */
unsigned long long vme_addr;/* Starting Address on the VMEbus
*/
unsigned long long size;/* Window Size */
vme_address_t aspace; /* Address Space */
vme_cycle_t cycle; /* Cycle properties */
vme_width_t dwidth; /* Maximum Data Width */
};
I'm not sure I follow.
1. I don't believe accessing 64k of the ZMI's VME address space is a
valid operation, could this be causing the bus to hang? Actually, I
have this doubt because I am unsure how exactly the master window is
setup.
Are you reading the whole of the 64k? From memory, the tsi148 has a minimum
window size of 64k, this should be fine as long as you don't read outside
the devices registers.
2. From the documentation of ZMI 4100, it is claimed that the board
supports VME64 and VME64X. However, I am not sure if master.cycle
bits for 2eVME need to be set or not?!
If you want to use the high speed block transfer modes, set them as required
in the cycle properties.
3. Is there away to prevent the bus from hanging by modifying tsi148
device code?
I'm not sure why it's hanging, I'm not familiar with the hardware which
doesn't help. Do you have a VME analyser to see what is actually happening
on the bus?
Thanks for reading this far, and any help is sincerely appreciated!
Hope that helps,
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.we...@ge.com | VAT:GB 927559189
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
