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

Tue Jun 24 11:19:40 UTC 2014

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) -> 'b0000   [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, 0x10000.  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.welch at 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 = 0x10000;
>>>           master.size = 0x10000;
>>>           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 0x10000.
>>
>> 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.welch at ge.com                  | VAT:GB 927559189
> _______________________________________________
> devel mailing list
> devel at linuxdriverproject.org
> http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
>

-- 
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 at ge.com                  | VAT:GB 927559189