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

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

[Maurice Moss]

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.  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
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 */
};

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.

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?!

3. Is there away to prevent the bus from hanging by modifying tsi148
device code?

Thanks for reading this far, and any help is sincerely appreciated!
Cheers,
MM
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

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

[Dan Carpenter]

I have added Martyn and Manohar to the CC list since they might know the
answer.  Are you using the latest kernel, btw?

regards,
dan carpenter

On Wed, Jun 04, 2014 at 02:43:29PM -0700, 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.  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
> 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 */
> };
> 
> 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.
> 
> 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?!
> 
> 3. Is there away to prevent the bus from hanging by modifying tsi148
> device code?
> 
> Thanks for reading this far, and any help is sincerely appreciated!
> Cheers,
> MM
> _______________________________________________
> devel mailing list
> devel@linuxdriverproject.org
> http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

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

[Martyn Welch]

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@ge.com                  | VAT:GB 927559189
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

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

[Maurice Moss]

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?

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?

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?

> 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

Cheers!

On Wed, Jun 11, 2014 at 10:36 AM, Martyn Welch <martyn.welch@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@ge.com                  | VAT:GB 927559189
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

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

[Martyn Welch]

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@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@ge.com                  | VAT:GB 927559189
> _______________________________________________
> devel mailing list
> devel@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@ge.com                  | VAT:GB 927559189
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

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

[Maurice Moss]

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@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@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@ge.com                  | VAT:GB 927559189
>>
>> _______________________________________________
>>
>> devel mailing list
>> devel@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@ge.com                  | VAT:GB 927559189
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

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

[Martyn Welch]

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@ge.com                  | VAT:GB 927559189
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

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

[Maurice Moss]

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@ge.com> 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@ge.com                  | VAT:GB 927559189
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

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

[Maurice Moss]

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@gmail.com> 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@ge.com> 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@ge.com                  | VAT:GB 927559189
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

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

[Maurice Moss]

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.

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!

On Thu, Jul 3, 2014 at 8:18 AM, Maurice Moss <eightplusclub@gmail.com> 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@gmail.com> 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@ge.com> 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@ge.com                  | VAT:GB 927559189
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

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

[Martyn Welch]

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@gmail.com> 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@gmail.com> 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@ge.com> 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@ge.com                  | 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@ge.com                  | VAT:GB 927559189
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

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

[Maurice Moss]

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.
1. Is there a way I can test whether the PCI bridge is working?
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 :-/
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.

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

On Wed, Jul 16, 2014 at 12:47 AM, Martyn Welch <martyn.welch@ge.com> 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@gmail.com>
>> 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@gmail.com>
>>> 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@ge.com>
>>>> 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@ge.com                  | 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@ge.com                  | VAT:GB 927559189
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

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

[Martyn Welch]

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@ge.com> 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@gmail.com>
>>> 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@gmail.com>
>>>> 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@ge.com>
>>>>> 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@ge.com                  | 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@ge.com                  | 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@ge.com                  | VAT:GB 927559189
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

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

[Maurice Moss]

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@ge.com> 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@ge.com>
>> 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@gmail.com>
>>>> 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@gmail.com>
>>>>> 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@ge.com>
>>>>>> 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@ge.com                  | 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@ge.com                  | 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@ge.com                  | VAT:GB 927559189
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

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

[Maurice Moss]

Hi Manohar/Dan,

Any idea regarding this?

Cheers,
Maurice

On Mon, Nov 3, 2014 at 5:25 PM, Maurice Moss <eightplusclub@gmail.com> 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@ge.com> 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@ge.com>
>>> 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@gmail.com>
>>>>> 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@gmail.com>
>>>>>> 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@ge.com>
>>>>>>> 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@ge.com                  | 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@ge.com                  | 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@ge.com                  | VAT:GB 927559189
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

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

[Welch, Martyn (GE Intelligent Platforms)]

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@ge.com

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@gmail.com]
> Sent: 08 November 2014 00:33
> To: Welch, Martyn (GE Intelligent Platforms)
> Cc: Manohar Vanga; dan.carpenter@oracle.com; driverdev-
> devel@linuxdriverproject.org
> 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@gmail.com>
> 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@ge.com>
> 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@ge.com>
> >>> 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@gmail.com>
> >>>>> 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@gmail.com>
> >>>>>> 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@ge.com>
> >>>>>>> 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@ge.com                  | 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@ge.com                  | 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@ge.com                  | VAT:GB 927559189
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

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

[Maurice Moss]

Hi Martyn,

Thanks for your reply. I have pasted the code below. It is very much
similar to your test code from the forum.

Thanks!

#define _XOPEN_SOURCE 500
#define u32 unsigned int
#include <stdio.h>
#include <stdlib.h>
#include <sys/ioctl.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
#include "vme_user.h"
int main(int argc, char *argv[])
{
        int fd;
        int i;
        int retval;
        int readSize = 2;
        unsigned char data[readSize];

        struct vme_master master;

        printf("Simple VME User Module Test\n");

        fd = open("/dev/bus/vme/m0", O_RDONLY);
        if (fd == -1) {
                perror("ERROR: Opening window device file");
                return 1;
        }

        printf ("opened the file\n");
        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);
        if (retval != 0) {
                printf("retval=%d\n", retval);
                perror("ERROR: Failed to configure window");
                return 1;
        }

        printf ("set the master\n");
        /*
         * Reading first 512 bytes
         */
        for (i=0; i<readSize; i++) {
                data[i] = 0;
        }

        retval = pread(fd, data, readSize, 0x03c);
        if (retval < readSize) {
                printf("WARNING: Only read %d bytes", retval);
        }

        for(i=0; i<retval; i++) {
                if (i % 8 == 0) {
                        printf("\n""%4.4x: ", i);
                }
                printf("%2.2x ", data[i]);
        }
        printf("\n");

        close(fd);

        return 0;
}

On Mon, Nov 10, 2014 at 4:07 AM, Welch, Martyn (GE Intelligent
Platforms) <martyn.welch@ge.com> wrote:
> 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@ge.com
>
> 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@gmail.com]
>> Sent: 08 November 2014 00:33
>> To: Welch, Martyn (GE Intelligent Platforms)
>> Cc: Manohar Vanga; dan.carpenter@oracle.com; driverdev-
>> devel@linuxdriverproject.org
>> 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@gmail.com>
>> 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@ge.com>
>> 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@ge.com>
>> >>> 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@gmail.com>
>> >>>>> 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@gmail.com>
>> >>>>>> 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@ge.com>
>> >>>>>>> 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@ge.com                  | 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@ge.com                  | 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@ge.com                  | VAT:GB 927559189
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

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

[Maurice Moss]

Hi Martyn,

Any update on this from your side?

Cheers!

On Mon, Nov 10, 2014 at 10:22 AM, Maurice Moss <eightplusclub@gmail.com> wrote:
> Hi Martyn,
>
> Thanks for your reply. I have pasted the code below. It is very much
> similar to your test code from the forum.
>
> Thanks!
>
> #define _XOPEN_SOURCE 500
> #define u32 unsigned int
> #include <stdio.h>
> #include <stdlib.h>
> #include <sys/ioctl.h>
> #include <sys/types.h>
> #include <sys/stat.h>
> #include <fcntl.h>
> #include <unistd.h>
> #include "vme_user.h"
> int main(int argc, char *argv[])
> {
>         int fd;
>         int i;
>         int retval;
>         int readSize = 2;
>         unsigned char data[readSize];
>
>         struct vme_master master;
>
>         printf("Simple VME User Module Test\n");
>
>         fd = open("/dev/bus/vme/m0", O_RDONLY);
>         if (fd == -1) {
>                 perror("ERROR: Opening window device file");
>                 return 1;
>         }
>
>         printf ("opened the file\n");
>         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);
>         if (retval != 0) {
>                 printf("retval=%d\n", retval);
>                 perror("ERROR: Failed to configure window");
>                 return 1;
>         }
>
>         printf ("set the master\n");
>         /*
>          * Reading first 512 bytes
>          */
>         for (i=0; i<readSize; i++) {
>                 data[i] = 0;
>         }
>
>         retval = pread(fd, data, readSize, 0x03c);
>         if (retval < readSize) {
>                 printf("WARNING: Only read %d bytes", retval);
>         }
>
>         for(i=0; i<retval; i++) {
>                 if (i % 8 == 0) {
>                         printf("\n""%4.4x: ", i);
>                 }
>                 printf("%2.2x ", data[i]);
>         }
>         printf("\n");
>
>         close(fd);
>
>         return 0;
> }
>
> On Mon, Nov 10, 2014 at 4:07 AM, Welch, Martyn (GE Intelligent
> Platforms) <martyn.welch@ge.com> wrote:
>> 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@ge.com
>>
>> 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@gmail.com]
>>> Sent: 08 November 2014 00:33
>>> To: Welch, Martyn (GE Intelligent Platforms)
>>> Cc: Manohar Vanga; dan.carpenter@oracle.com; driverdev-
>>> devel@linuxdriverproject.org
>>> 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@gmail.com>
>>> 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@ge.com>
>>> 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@ge.com>
>>> >>> 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@gmail.com>
>>> >>>>> 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@gmail.com>
>>> >>>>>> 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@ge.com>
>>> >>>>>>> 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@ge.com                  | 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@ge.com                  | 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@ge.com                  | VAT:GB 927559189
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel