Re: XVME 6300 with TSI148 bridge on 64 bit Debian (Linux 3.2.57) vme_user issue

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Driver Backports]     [DMA Engine]     [Linux GPIO]     [Linux SPI]     [Video for Linux]     [Linux USB Devel]     [Linux Coverity]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux