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.welch@xxxxxx 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:eightplusclub@xxxxxxxxx] > Sent: 08 November 2014 00:33 > To: Welch, Martyn (GE Intelligent Platforms) > Cc: Manohar Vanga; dan.carpenter@xxxxxxxxxx; driverdev- > devel@xxxxxxxxxxxxxxxxxxxxxx > 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 <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
