I have done some tests based on your email. I will try to summarise. I hope this isn't getting too detailed for a tech-talk rather than private exchange. It seems to have the potential for wider use in the future but if anyone feels differently please say.
First off I tried some of the IOC commands as suggested:
epics> pcidiagset 0x81 0 0
Looking for 81:0.0
Mapping 81:0.0
BAR 0 from 0x7f180a66a000 for 262144 bytes
epics> pciread 32 0 0x64
0x00000000 00010000 02000002 00000005 00000000
0x00000010 00000000 00000000 00000000 00000000
0x00000020 00001000 00110000 00110000 17060207
0x00000030 00000000 00000000 00000000 00000000
0x00000040 00000000 00000000 00000000 0000008e
0x00000050 40000200 00000000 00000000 00000000
0x00000060 00000000
epics> pciwrite 32 4 0
epics> pciread 32 0 0x64
0x00000000 00000100 00000000 05000000 00000000
0x00000010 00000000 00000000 00000000 00000000
0x00000020 00100000 00001100 00001100 07020617
0x00000030 00000000 00000000 00000000 00000000
0x00000040 00000000 00000000 00000000 8e000000
0x00000050 00020040 00000000 00000000 00000000
0x00000060 00000000
epics> pciwrite 32 4 0x02000002
epics> pciread 32 0 0x64
0x00000000 00010000 02000002 00000005 00000000
0x00000010 00000000 00000000 00000000 00000000
0x00000020 00001000 00110000 00110000 17060207
0x00000030 00000000 00000000 00000000 00000000
0x00000040 00000000 00000000 00000000 0000008e
0x00000050 40000200 00000000 00000000 00000000
0x00000060 00000000
Having done that I tried some modifications to the block of code pointed out in drvemSetup.cpp, rebuilding mrfioc2 and the IOC in each case, re-started the IOC and executed some commands at the IOC. The following are code snippets plus the IOC commands and output.
======================================================
// Disable EVR and set byte order to big endian
NAT_WRITE32(evr, Control, 0);
// Enable byte order swapping if necessary
// #if EPICS_BYTE_ORDER == EPICS_ENDIAN_LITTLE
// BE_WRITE32(evr, Control, 0x02000000);
BE_WRITE32(evr, Control, 0x0);
// #endif
epics> mrmEvrSetupPCI("EVR-01", "81:0.0")
Notice: devPCIFindSpec() expect B:D.F in hex
Device EVR-01 129:0.0 slot=6
Using IRQ 88
FWVersion 0x17060207
Found version 519
Found SFP Strangeness 00070403
Sequencer capability detected
PCIe: Out FP:0 FPUNIV:16 RB:0 IFP:2 GPIO:0
Enabling interrupts
EVR FIFO task start
epics> pciread 32 0 0x64
0x00000000 00000100 00000000 05000000 00000000
0x00000010 00000000 00000000 00000000 00000040
0x00000020 00100000 00001100 00001100 07020617
0x00000030 00000000 00000000 00000000 00000000
0x00000040 00000000 00000000 00000000 8e000000
0x00000050 00020040 00000000 00000000 00000000
0x00000060 00000000
======================================================
// Disable EVR and set byte order to big endian
NAT_WRITE32(evr, Control, 0);
// Enable byte order swapping if necessary
// #if EPICS_BYTE_ORDER == EPICS_ENDIAN_LITTLE
BE_WRITE32(evr, Control, 0x02000000);
// BE_WRITE32(evr, Control, 0x0);
// #endif
epics> mrmEvrSetupPCI("EVR-01", "81:0.0")
Notice: devPCIFindSpec() expect B:D.F in hex
Device EVR-01 129:0.0 slot=6
Using IRQ 88
FWVersion 0x07020617
Error: Firmware does not correspond to an EVR
epics> pciread 32 0 0x64
0x00000000 00010000 02000002 00000005 00000000
0x00000010 00000000 00000000 00000000 40000000
0x00000020 00001000 00110000 00110000 17060207
0x00000030 00000000 00000000 00000000 00000000
0x00000040 00000000 00000000 00000000 0000008e
0x00000050 40000200 00000000 00000000 00000000
0x00000060 00000000
======================================================
// Disable EVR and set byte order to big endian
NAT_WRITE32(evr, Control, 0);
// Enable byte order swapping if necessary
#if EPICS_BYTE_ORDER == EPICS_ENDIAN_LITTLE
// BE_WRITE32(evr, Control, 0x02000000);
BE_WRITE32(evr, Control, 0x0);
#endif
epics> mrmEvrSetupPCI("EVR-01", "81:0.0")
Notice: devPCIFindSpec() expect B:D.F in hex
Device EVR-01 129:0.0 slot=6
Using IRQ 88
FWVersion 0x17060207
Found version 519
Found SFP Strangeness 00070403
Sequencer capability detected
PCIe: Out FP:0 FPUNIV:16 RB:0 IFP:2 GPIO:0
EVR FIFO task start
Enabling interrupts
epics> pciread 32 0 0x64
0x00000000 00000100 00000000 05000000 00000000
0x00000010 00000000 00000000 00000000 00000040
0x00000020 00100000 00001100 00001100 07020617
0x00000030 00000000 00000000 00000000 00000000
0x00000040 00000000 00000000 00000000 8e000000
0x00000050 00020040 00000000 00000000 00000000
0x00000060 00000000
======================================================
Rather a lot sorry.
At the end of all that it seems that BE_WRITE32(evr, Control, 0x0) is necessary rather than BE_WRITE32(evr, Control, 0x02000000)? Correct?
Does the mrmEvrSetupPCI output look sensible? The "Found SFP Strangeness 00070403" seems a little worrying?
Any further thoughts on how to address this properly?
Steve
________________________________
From: Michael Davidsaver <[email protected]>
Sent: 10 August 2018 16:35:44
To: Kinder, Steve (STFC,DL,TECH)
Cc: EPICS
Subject: Re: mrfioc2 Linux driver
On 08/10/2018 06:31 AM, Steve Kinder - UKRI STFC wrote:
> # uname -a
> Linux TST-T02-IOC-CS-02.dl.ac.uk 3.10.0-514.6.1.el7.x86_64 #1 SMP Tue Jan 17 11:12:41 CST 2017 x86_64 x86_64 x86_64 GNU/Linux
So x86, I just wanted to be certain. In the IOC shell run:
> pcidiagset 81 0 0
> pciread 32 0 0x64
The Version register is offset 0x2c. The control register (0x4)
has a bit which enables byte order swapping for all registers
(including Control).
The sequence which sets this up is:.
https://github.com/epics-modules/mrfioc2/blob/master/evrMrmApp/src/drvemSetup.cpp#L575-L580
which I've not had problems with before.
If you want to go further you can run
> pcidiagset 81 0 0
> pciwrite 32 4 0
> pciread 32 0 0x64
> pciwrite 32 4 0x02000002
> pciread 32 0 0x64
One of these (I think the second) should show Version==0x17060207
> ________________________________
> From: Michael Davidsaver <[email protected]>
> Sent: 10 August 2018 13:14:11
> To: Kinder, Steve (STFC,DL,TECH)
> Cc: EPICS
> Subject: Re: mrfioc2 Linux driver
>
> Steve, It looks like the value read from the Version register is backwards. 0x17 should be the MSB. What does "uname -r" show?
>
> On Fri, Aug 10, 2018, 4:37 AM Steve Kinder - UKRI STFC <[email protected]<mailto:[email protected]>> wrote:
> Sorry to have more questions. But I am going in the right direction.
>
>
> On calling the setup from the IOC I now get:
>
>
> epics> mrmEvrSetupPCI("EVR-01", "81:0.0")
> Device EVR-01 129:0.0 slot=6
> Using IRQ 88
> FWVersion 0x07020617
> Error: Firmware does not correspond to an EVR
>
> Is this a symptom of using 2-2-0? Or is there some simpler explanation/solution? Sounds like the firmware isn't compatible with the support module and/or driver?
>
>
> Steve
>
>
> ________________________________
> From: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> on behalf of Steve Kinder - UKRI STFC <[email protected]<mailto:[email protected]>>
> Sent: 07 August 2018 16:40:53
> To: [email protected]<mailto:[email protected]>
> Subject: mrfioc2 Linux driver
>
> Hello all
>
>
> I am trying to get an MRF PCIe-EVR-300DC configured and working on Linux using mrfioc2. I think I have an IOC built. I think I have some understanding of the parameters to mrmEvrSetupPCI(EVR-01, 1, 0, 0, 0). I could well be wrong on those but that isn't the source of my immediate problem. Executing the previous call gives:
>
>
> Can't open /sys/module/mrf/parameters/interfaceversion in order to read kernel module interface version. Is kernel module loaded?
>
>
> I found some documentation that indicates an MRF kernel driver is also required:
>
>
> $ make -C /location/of/mrmShared/linux \
>
> KERNELDIR=/lib/modules/`uname -r`/build modules_install
>
> $ sudo depmod -a
>
> $ sudo modprobe mrf
>
>
> I seem to need to execute the first line as root or I get permissions problems. However then I get:
>
>
> # make -C /home/controls/work/R3.14.12.5/support/mrfioc2/3-0-0/mrmShared/linux KERNELDIR=/lib/modules/`uname -r`/build modules_install
> make: Entering directory `/home/controls/work/R3.14.12.5/support/mrfioc2/3-0-0/mrmShared/linux'
> make -C /lib/modules/3.10.0-514.6.1.el7.x86_64/build M=/home/controls/work/R3.14.12.5/support/mrfioc2/3-0-0/mrmShared/linux modules_install
> make[1]: Entering directory `/usr/src/kernels/3.10.0-514.6.1.el7.x86_64'
> Makefile:641: Cannot use CONFIG_CC_STACKPROTECTOR_STRONG: -fstack-protector-strong not supported by compiler
> DEPMOD 3.10.0-514.6.1.el7.x86_64
> make[1]: Leaving directory `/usr/src/kernels/3.10.0-514.6.1.el7.x86_64'
> make: Leaving directory `/home/controls/work/R3.14.12.5/support/mrfioc2/3-0-0/mrmShared/linux'
>
>
> The documentation dates back to 2015, Rev 7, so may be out of date?
>
>
> Any advice/help would be much appreciated. Further documentation?
>
>
> My kernel is 3.10.0-514.6.1.el7.x86_64, mrfioc2 3-0-0
>
>
> Thanks
>
>
> Steve
>
>
> d
> o
> m
> o
> d
> p
> r
> o
> b
> e
> m
> r
> f
>
- Replies:
- Re: mrfioc2 Linux driver Michael Davidsaver
- References:
- mrfioc2 Linux driver Steve Kinder - UKRI STFC
- Re: mrfioc2 Linux driver Steve Kinder - UKRI STFC
- Re: mrfioc2 Linux driver Michael Davidsaver
- Re: mrfioc2 Linux driver Steve Kinder - UKRI STFC
- Re: mrfioc2 Linux driver Michael Davidsaver
- Navigate by Date:
- Prev:
RE: EDM X/Y Plot segfaults Sinclair, John William
- Next:
Re: mrfioc2 Linux driver Michael Davidsaver
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
<2018>
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: mrfioc2 Linux driver Michael Davidsaver
- Next:
Re: mrfioc2 Linux driver Michael Davidsaver
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
<2018>
2019
2020
2021
2022
2023
2024
|
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·