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 0000:02:04.0: enabling device (0140 -> 0143) [ 76.192893] vme_ca91cx42 0000:02:04.0: Board is the VME system controller [ 76.192902] vme_ca91cx42 0000:02:04.0: Slot ID is 0 [ 76.192907] vme_ca91cx42 0000:02:04.0: CR/CSR Offset: 0 [ 76.192911] vme_ca91cx42 0000:02:04.0: Slot number is unset, not configuring CR/CSR space [ 76.195956] vme_ca91cx42 0000: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 = 0x10000; 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 f7d00000 (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: f7000000-f78fffff Prefetchable memory behind bridge: 00000000f6000000-00000000f6ffffff 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.welch@xxxxxx> 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 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