XVME 6300 with TSI148 bridge on 64 bit Debian (Linux 3.2.57) vme_user issue
Maurice Moss
eightplusclub at gmail.com
Wed Jul 2 23:47:32 UTC 2014
Hi Martyn,
Thanks a lot for your guidance. I am back working on vme and I am
trying it with a newer kernel, and I seem to have gone backwards!
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
[ 1.879625] vme_user: VME User Space Access Driver
[ 1.879846] vme_tsi148 0000:04:04.0: Board is the VME system controller
[ 1.879849] vme_tsi148 0000:04:04.0: VME geographical address is 0
[ 1.879851] vme_tsi148 0000:04:04.0: VME Write and flush and error
check is enabled
[ 1.880240] vme_tsi148 0000:04:04.0: CR/CSR Offset: 0
[ 1.880244] vme_tsi148 0000:04:04.0: Enabling CR/CSR space
Any help is sincerely appreciated :)
Cheers!
On Tue, Jun 24, 2014 at 4:19 AM, Martyn Welch <martyn.welch at ge.com> wrote:
> 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
More information about the devel
mailing list