Experimental Physics and
Industrial Control System

Steve Kinder - UKRI STFC <[email protected]> · Tue, 14 Aug 2018 08:53:17 +0000

Hi Michael

I thought I had taken all those changes out. Anyway I re-downloaded devlib2/2-9 and mrfioc/2-2-0, built these from scratch, rebuilt my IOC against them, rebuilt and re-installed the mrf driver.

I believe all looks ok now! See below. I must have left something in by mistake. Many apologies and many thanks for all your help.

Steve

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 EEPROM
Sequencer capability detected
PCIe: Out FP:0 FPUNIV:16 RB:0 IFP:2 GPIO:0
Enabling interrupts
EVR FIFO task start
epics> pcidiagset 0x81 0 0
Looking for 81:0.0
Mapping 81:0.0
BAR 0 from 0x7f8711b78000 for 262144 bytes
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

________________________________
From: Michael Davidsaver <[email protected]>
Sent: 13 August 2018 23:01:12
To: Kinder, Steve (STFC,DL,TECH)
Cc: EPICS
Subject: Re: mrfioc2 Linux driver

On 08/13/2018 10:19 AM, Steve Kinder - UKRI STFC wrote:
...
> First off I tried some of the IOC commands as suggested:
...
> epics> pciwrite 32 4 0
> epics> pciread 32 0 0x64
> 0x00000000 00000100 00000000 05000000 00000000
> 0x00000020 00100000 00001100 00001100 07020617

Ok, with the Control[LEMDE] bit cleared (big endian), the Version
is read in reverse order (0x07020617).

> epics> pciwrite 32 4 0x02000002
> epics> pciread 32 0 0x64
> 0x00000000 00010000 02000002 00000005 00000000
> 0x00000020 00001000 00110000 00110000 17060207

With LEMDE set (little endian), Version is read correctly (0x17060207).

This is exactly what I would expect on an x86 host.
So this is not a hardware issue, nor an issue with the MMIO access
calls (used by pciread/write).

> NAT_WRITE32(evr, Control, 0)
> #if EPICS_BYTE_ORDER == EPICS_ENDIAN_LITTLE
>         BE_WRITE32(evr, Control, 0x02000000);
> #endif

This logic is then first ensuring that LEMDE is clear (big endian).
Then execute a write to set LEMDE only.  BE_WRITE32() on x86
will swap the value written.

On 08/10/2018 08:28 AM, Steve Kinder - UKRI STFC wrote:
> ... The solution applied there was to modify mrfCommonIO.h, redefining "NAT_ macros to be_ functions". ...

It should not be necessary to make this change to mrfioc2 2.2.0 (or 2.1.0
for that matter), but doing so would result in the behavior you describe.
Sorry that I didn't pick up on this sooner.  Can you test with an unmodified
copy of mrfioc2 2.2.0 and devlib2 2.9?

I've previously verified this code with both powerpc/RTEMS and
x86/Linux targets.  So I've quite confident this recipe works.

Also, for completeness which Base version are you using?

> Does the mrmEvrSetupPCI output look sensible? The "Found SFP Strangeness 00070403" seems a little worrying?

The SFP eeprom readout code doesn't use the MRF register access macros
as it's not MRF, nor word registers.  It needs LEMDE to be set.
(The SFP info non-essential, so you could just ignore this)

https://github.com/epics-modules/mrfioc2/blob/07a798060aecc454206fd7f0638339682b7bffb2/mrmShared/src/sfp.cpp#L59

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System