Hi Manohar/Dan, Any idea regarding this? Cheers, Maurice On Mon, Nov 3, 2014 at 5:25 PM, Maurice Moss <eightplusclub@xxxxxxxxx> 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 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
