Unable to change configuration space on Ryzen

[waterbear515]

Hey Ufrisk! Thank you so much for PCILeach; it's a masterpiece. I've watched all your presentations on YouTube and have been following this project for a long time. I'm excited to start using it more and hopefully contribute in any way I can.

I recently got myself a new Screamer M2 and have it working great on my AMD Ryzen system. Everything is working perfectly, except I'm unable to alter the configuration space with the directions you have here: https://github.com/ufrisk/pcileech-fpga/blob/master/ScreamerM2/build.md

Sample probe for verification:

pcileech.exe probe -device fpga -v

DEVICE: FPGA: ScreamerM2 PCIe gen2 x1 [300,0,500] [v4.3,0100]
 Memory Map:
 START              END               #PAGES
 0000000000000000 - 000000000009ffff  000000a0
 00000000000c0000 - 00000000deffffff  000def40
 00000000e0000000 - 00000000f1ffffff  00012000
 00000000f5000000 - 00000000f5ffffff  00001000
 00000000f60fc000 - 00000000f60fffff  00000004
 00000000f6400000 - 00000000f67fffff  00000400
 00000000f6840000 - 00000000f6848fff  00000009
 00000000f6850000 - 00000000f6850fff  00000001
 00000000f6b00000 - 00000000f6bfffff  00000100
 00000000f6efc000 - 00000000f6f23fff  00000028
 00000000f7000000 - 00000000f7003fff  00000004
 00000000f7200000 - 00000000f72fffff  00000100
 00000000f73f0000 - 00000000f73f7fff  00000008
 0000000100000000 - 000000081f2fffff  0071f300

 Current Action: Probing Memory
 Access Mode:    Normal
 Progress:       33267 / 33267 (100%)
 Speed:          449 MB/s
 Address:        0x000000081F300000
 Pages read:     8460578 / 8516352 (99%)
 Pages failed:   55774 (0%)
Memory Probe: Completed.

I've set the Device/Vendor ID's to random values that are working. Below is the info on the device:

# lspci -nn -d 2c5b:0440 -vv -xxxx
01:00.0 Non-VGA unclassified device [0000]: Device [2c5b:0440]
        Subsystem: Device [2bfc:0007]
        Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ >SERR- <PERR- INTx-
        Interrupt: pin A routed to IRQ 255
        Region 0: Memory at f7704000 (32-bit, non-prefetchable) [disabled]
        Region 4: Memory at f7702000 (32-bit, non-prefetchable) [disabled]
        Region 5: Memory at f7700000 (32-bit, non-prefetchable) [disabled]
        Capabilities: [40] Power Management version 3
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
                Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [48] MSI: Enable- Count=1/1 Maskable- 64bit+
                Address: 0000000000000000  Data: 0000
        Capabilities: [60] Express (v2) Endpoint, MSI 00
                DevCap: MaxPayload 512 bytes, PhantFunc 0, Latency L0s unlimited, L1 unlimited
                        ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset- SlotPowerLimit 0.000W
                DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
                        RlxdOrd+ ExtTag+ PhantFunc- AuxPwr- NoSnoop+
                        MaxPayload 512 bytes, MaxReadReq 512 bytes
                DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
                LnkCap: Port #0, Speed 5GT/s, Width x1, ASPM L0s, Exit Latency L0s unlimited
                        ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp-
                LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+
                        ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
                LnkSta: Speed 5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
                DevCap2: Completion Timeout: Range B, TimeoutDis-, LTR-, OBFF Not Supported
                DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled
                         AtomicOpsCtl: ReqEn-
                LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-
                         Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
                         Compliance De-emphasis: -6dB
                LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1-
                         EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
00: fb 1c 80 03 00 00 10 20 00 00 00 00 10 00 00 00
10: 00 40 70 f7 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 20 70 f7 00 00 70 f7 00 00 00 00 fb 1c 06 00
30: 00 00 00 00 40 00 00 00 00 00 00 00 ff 01 00 00
40: 01 48 03 78 08 00 00 00 05 60 80 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 10 00 02 00 e2 8f 00 00 50 29 00 00 12 f4 03 00
70: 40 00 12 10 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00
90: 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 ff ff ff ff ff ff ff ff
b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

Screenshot of Vivado Ext Capabilities

pcileech_fifo.sv

rw[199:192] <= 8'h00;                       // +018: CFG_REV_ID
rw[200]     <= 1'b1;                        // +019: PCIE CORE RESET
rw[201]     <= 1'b0;                        //       PCIE SUBSYSTEM RESET
rw[202]     <= 1'b1;                        //       CFGTLP PROCESSING ENABLE
rw[203]     <= 1'b0;                        //       CUSTOM CONFIGURATION SPACE ENABLED
rw[204]     <= 1'b1;                        //       CFGTLP FILTER TLP FROM USER
rw[205]     <= 1'b1;                        //       CLK_IS_ENABLED [if clk not started _pcie_core_config[77] will remain zero].

As a test, I altered the pcileech_cfgspace.coe file to random values I found on Google:

memory_initialization_radix=16;
memory_initialization_vector=
ff,
ab,
f0,
11,
11,
00,
01,
aa,
bb,
cc,
dd,
ef,
ee,
ff,
00,
ff;

However, no matter what I change that file to, or what I alter inside Vivado or any of the source files, the configuration space never changes from:

00: fb 1c 80 03 00 00 10 20 00 00 00 00 10 00 00 00
10: 00 40 70 f7 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 20 70 f7 00 00 70 f7 00 00 00 00 fb 1c 06 00
30: 00 00 00 00 40 00 00 00 00 00 00 00 ff 01 00 00
40: 01 48 03 78 08 00 00 00 05 60 80 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 10 00 02 00 e2 8f 00 00 50 29 00 00 12 f4 03 00
70: 40 00 12 10 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00
90: 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 ff ff ff ff ff ff ff ff
b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

It remains the same even if I don't enable custom configuration space, or enable with the default pcileech_cfgspace.coe that's provided. (With the exception of a few values at the start which I assume are from Xilinx?). I even tried disabling the configuration space entirely from within Vivado, but that had no change.

Am I doing something incorrectly, or is there anything else I can try?

[ufrisk]

The memory_initialization_vector= is wrong, you group the bytes "per byte" instead of required "per dword", as seen in ip/pcileech_cfgspace.coe. Use original ip/pcileech_cfgspace.coe and try if it works, if it does, edit it and keep the commas where they are...

To test from the start just edit rw[203] <= 1'b1; // CFGTLP ZERO DATA to set it to rw[203] <= 1'b0; in pcileech_fifo.sv, then generate project and have a look. Change value-by-value if you need to in the core itself after that. For just the config space you do not need to change stuff in the core just the line above.

[waterbear515]

@ufrisk Thanks so much for getting back to me! I tried to be very careful and do exactly what you suggested.

1. I started with a brand new clone of the repository:

$ git clone https://github.com/ufrisk/pcileech-fpga.git
Cloning into 'pcileech-fpga'...
remote: Enumerating objects: 489, done.
Receiving objects:  99% (485/489)used 0 (delta 0), pack-reused 489
Receiving objects: 100% (489/489), 600.66 KiB | 5.22 MiB/s, done.
Resolving deltas: 100% (339/339), done.

2. I changed line 253 in pcileech_fifo.sv to:

rw[203]     <= 1'b0;                        //       CFGTLP ZERO DATA

3. I opened Vivado Shell and ran:

$ source vivado_generate_project.tcl -notrace
...
$ source vivado_build.tcl -notrace
...
-------------------------------------------------------
 BUILD HOPEFULLY COMPLETED.
-------------------------------------------------------

4. I flashed the device with the new build:

$ openocd -f flash_screamer.cfg
Open On-Chip Debugger 0.10.0+dev-01213-g968d3851-dirty (2020-05-04-21:53)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
DEPRECATED! use 'adapter driver' not 'interface'
Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.
DEPRECATED! use 'adapter speed' not 'adapter_khz'
Info : ftdi: if you experience problems at higher adapter clocks, try the command "ftdi_tdo_sample_edge falling"
Info : clock speed 10000 kHz
Info : JTAG tap: xc7.tap tap/device found: 0x0362d093 (mfg: 0x049 (Xilinx), part: 0x362d, ver: 0x0)
Info : JTAG tap: xc7.tap tap/device found: 0x0362d093 (mfg: 0x049 (Xilinx), part: 0x362d, ver: 0x0)
...
shutdown command invoked

5. I looked at the new configuration space:

# lspci -nn -d 10ee:0666 -vv -xxxx
01:00.0 Ethernet controller [0200]: Xilinx Corporation Device [10ee:0666] (rev 02)
        Subsystem: Xilinx Corporation Device [10ee:0007]
        Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Interrupt: pin A routed to IRQ 255
        Capabilities: [40] Power Management version 3
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
                Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [48] MSI: Enable- Count=1/1 Maskable- 64bit+
                Address: 0000000000000000  Data: 0000
        Capabilities: [60] Express (v2) Endpoint, MSI 00
                DevCap: MaxPayload 512 bytes, PhantFunc 0, Latency L0s unlimited, L1 unlimited
                        ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset- SlotPowerLimit 0.000W
                DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
                        RlxdOrd+ ExtTag+ PhantFunc- AuxPwr- NoSnoop+
                        MaxPayload 128 bytes, MaxReadReq 512 bytes
                DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
                LnkCap: Port #0, Speed 5GT/s, Width x1, ASPM L0s, Exit Latency L0s unlimited
                        ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp-
                LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk-
                        ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
                LnkSta: Speed 5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
                DevCap2: Completion Timeout: Range B, TimeoutDis-, LTR-, OBFF Not Supported
                DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled
                         AtomicOpsCtl: ReqEn-
                LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-
                         Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
                         Compliance De-emphasis: -6dB
                LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1-
                         EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
00: ee 10 66 06 00 00 10 00 02 00 00 02 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 ee 10 07 00
30: 00 00 00 00 40 00 00 00 00 00 00 00 ff 01 00 00
40: 01 48 03 78 08 00 00 00 05 60 80 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 10 00 02 00 e2 8f 00 00 10 29 00 00 12 f4 03 00
70: 00 00 12 10 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00
90: 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 ff ff ff ff ff ff ff ff
b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

6. I compared this with the previous configuration space:

I can confirm that that there are a few small changes, but I was expecting something more dramatic and more inline with your tweet from January:

Is there any way I can change all the ff's to how they appear in the .coe file / your tweet, or is this a bug with the Screamer M2?

[ufrisk]

I'll double check this in the weekend. I've tested this on the ScreamerM2 since before so it's not a bug with the hardware so no worries about that at the very least.

[waterbear515]

Thank you!! I really appreciate the help. I'll stand by for now.

[ufrisk]

This is more than strange.

I did exactly what you did, in exactly that order according to (1), (2), (3).

Only difference is that I've built it on Windows and that I've also flashed it with a Xilinx programming cable from within Vivado. But your flash of the device with OpenOCD is clearly successful so it's not that. Also I just don't see how building it on Linux instead of Windows could do this.

Only thing I can come to think about is that the pcileech_cfgspace.coe seems to be containing Windows line endings \r\n instead of unix \n, but it seems to be a very strange bug if that was the case.

Or if this is some strange timing issue; it's a bit strange that your previous bistream (the once you are comparing to) also ways 0xff everywhere in the upper unused part of cfgspace when it really should say 0x00 if things would work as intended. It would be interesting to see what result the stock bitstream would yield; if it would say 0x00 or 0xff in the upper bytes of lspci output...

[waterbear515]

Again, I really appreciate your help with this. I hope we can uncover something that helps out everyone who loves this project! 💪

I'm also on windows, using Cgwin and lspci from https://eternallybored.org/misc/pciutils/

My full environment is:

• Windows 10 1909
• Vivado v2019.2 (64bit)
• Cygwin64
• openocd v0.10.0 compiled in Cygwin64 with the 4 byte patch
• pciutils v3.5.5 (lspci)
• ScreamerM2
• LambdaConcept JTAGSerial board/cable
• I use the console cmder which is why my commands look they're from linux
• openocd flash config:

  
  interface ftdi
  ftdi_vid_pid 0x0403 0x6011
  ftdi_channel 0
  ftdi_layout_init 0x0098 0x008b
  reset_config none

source [find cpld/xilinx-xc7.cfg] source [find cpld/jtagspi.cfg] adapter_khz 10000

proc fpga_program {} { global _CHIPNAME xc7_program $_CHIPNAME.tap }

init jtagspi_init 0 bscan_spi_xc7a35t.bit jtagspi_program pcileech_screamer_m2_top.bin 0x0 fpga_program shutdown

So far the only real difference between our environments seems to be Openocd and the Xilinx programming cable.

I thought about what you said and decided to run a few tests:

**I flashed the pre-built bitstream, version 4.1**

lspci -nn -vv -d 10ee:0666 -xxxx

01:00.0 Ethernet controller [0200]: Xilinx Corporation Device [10ee:0666] (rev 02) 00: ee 10 66 06 00 00 10 00 02 00 00 02 00 00 00 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 ee 10 07 00 30: 00 00 00 00 40 00 00 00 00 00 00 00 ff 01 00 00 40: 01 48 03 78 08 00 00 00 05 60 80 00 00 00 00 00 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 10 00 02 00 e2 8f 00 00 10 29 00 00 12 f4 03 00 70: 00 00 12 10 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 90: 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

**Then I flashed the pre-built version 4.2**

lspci -nn -d 10ee:0666 -xxxx

01:00.0 Ethernet controller [0200]: Xilinx Corporation Device [10ee:0666] (rev 02) 00: ee 10 66 06 00 00 10 00 02 00 00 02 00 00 00 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 ee 10 07 00 30: 00 00 00 00 40 00 00 00 00 00 00 00 ff 01 00 00 40: 01 48 03 78 08 00 00 00 05 60 80 00 00 00 00 00 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 10 00 02 00 e2 8f 00 00 10 29 00 00 12 f4 03 00 70: 00 00 12 10 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 90: 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 ff ff ff ff ff ff ff ff b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

**Then I flashed the pre-built bitstream, version 4.3**

lspci -nn -d 10ee:0666 -xxxx

01:00.0 Ethernet controller [0200]: Xilinx Corporation Device [10ee:0666] (rev 02) 00: ee 10 66 06 00 00 10 00 02 00 00 02 00 00 00 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 ee 10 07 00 30: 00 00 00 00 40 00 00 00 00 00 00 00 ff 01 00 00 40: 01 48 03 78 08 00 00 00 05 60 80 00 00 00 00 00 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 10 00 02 00 e2 8f 00 00 10 29 00 00 12 f4 03 00 70: 00 00 12 10 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 90: 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 ff ff ff ff ff ff ff ff b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

All pre-built bitstreams were downloaded from the links you provided here: https://github.com/ufrisk/pcileech-fpga/tree/master/ScreamerM2

The ff's only show up after version 4.2, which included the ability to set a custom configuration space.

If the pre-built bitstreams in version 4.2+ for you show a different configuration space than mine, then it would be logical to conclude the problem is with openocd and/or the lambdaconcept programming cable which would be really weird... With openocd we have to use the proxy bitstreams from here https://github.com/quartiq/bscan_spi_bitstreams. Could the issue could have something to do with that?

[ufrisk]

Thanks. In 4.1 and earlier the Xilinx PCIe core answered 0x00 on all extended configuration space reads. In 4.2 I introduced custom configuration space, which means I built a separate logic for processing configuration space requests. This logic is always active in 4.2+ even if you have not configured your own configuration space. It's supposed to answer with 0x00 - in effect make it look the same as in 4.1. Reason for this is that it simplifies user configuration.

My guess is that this is some timing issue. Which may make it very tricky to resolve. If we're lucky they did something to the Linux kernel in the latest releases which should allow me to reproduce the issue. If unlucky I'll need to purchase a similar system to yours to debug; which is not likely to happen since this is a hobby project of mine.

Anyway; it's clear this is not an OpenOCD issue; or a Windows/Linux issue for that matter.

Two questions:

• which linux distro and version are you running - could you do a uname -r for me so I also see the exact kernel version.
• which system are you running? CPU and Mobo.

[waterbear515]

Ok, that makes sense.

I'm on Windows 10 1909 with Cygwin64

$ uname -r
3.1.4(0.340/5/3)

• CPU: AMD Ryzen 9 3900x
• Mothorboard: https://www.gigabyte.com/us/Motherboard/X570-AORUS-XTREME-rev-1x Bios Version F11
• RAM: G.Skill Trident Z Neo 32.0 GB

I discovered something else interesting in my testing. V4.2+ hang on startup for about 10s until it finally proceeds. I also can't boot into a Linux Live CD with it either because it will hang indefinitely, and using simple lspci commands will freeze the computer for about 2s before working. However, V4.1 doesn't have any of those issues. The system will boot immediately as if the ScreamerM2 isn't even in it, and I have no issues booting into Live CDs or anything else. Since I'm unable to change the configuration space anyway, I'll be going back to 4.1.

[ufrisk]

Oh, I did not know you could run lspci in cygwin. I've tried it on my 1909 windows now and "sadly" it shows the correct config space for me - i.e. no errors there.

So it's some kind of timing issue is still my best guess. This also makes this very hard for me to debug since I don't have a ryzen system that I really can try this on; and I'm not too keen on purchasing one due to the $$$ when I'm not really in the need to upgrade my workstation...

I'll think about it for a while to see if I can come up with something; or if I get access to a ryzen system somehow.

[ufrisk]

This issue should now be resolved with the v4.4 version of the FPGA bitstream published at: https://github.com/ufrisk/pcileech-fpga. I'm closing this issue.

This v4.4 release also comes with other stability fixes so I'd suggest flashing this one onto your ScreamerM2 if able to.

Note! that PCILeech/MemProcFS still have some issues with regards to AMD Ryzen that will be fixed in software in a separate release. Since I'm doing pretty much a complete rewrite of large parts this is due in August/September unfortunately. But all FPGA related issues should now hopefully be resolved.

Good Luck, and Thank You for reporting helping me to improve upon PCILeech :)