Some PCIe cards may not be detected on certain OSes

[miczyg1]

mPCIe extension cards often require correct kernel modules/drivers and/or firmware blobs. If the card is not detected, be sure to check whether all needed modules and drivers are present on the system.

Also have a look at the mPCIe capabilities and connection to mPCIe ports on apu boards: https://github.com/pcengines/apu2-documentation/blob/master/docs/APU_mPCIe_capabilities.md Certain cards may require USB signals or SIM cards signals connected to the port. Be sure to match the mPCIe card requirements with correct mPCIe port to enable all features of the module.

[nicklowe]

Thanks for adding this. There may be other related issues, however. I don't think this covers:

http://pcengines.info/forums/?page=post&id=DB3EE6E0-9ABA-4E0D-9960-9A995DD20B91&fid=DF5ACB70-99C4-4C61-AFA6-4C0E0DB05B2A

http://pcengines.info/forums/?page=post&id=68A48B1E-5F35-40BB-B4B9-10C362A92F3B&fid=DC038CE7-688B-4FD7-A449-014010E444D1

I suspect this is occurring because of a coreboot interoperability issue.

Could the suggestion from QCA be followed up if it is not on the radar currently?

"QCA had helped to look at the problem and found that the incompatible motherboard’s CPU-PCIe-TX signal came out 150ms after PCIe-reset, unlike common Intel motherboards in the market, which had the CPU-PCIe-TX signal out in about 30ms after PCIe-reset. QCA believed that the timing of the CPU-PCIe-TX signal can be altered through BIOS."

https://bugzilla.kernel.org/show_bug.cgi?id=84821#c48

[miczyg1]

@nicklowe thank You for Your feedback. We simply do not possess all possible hardware to test, but now we can consider equiping our apus with those modules to fix the problem, thanks to Your input.

We will try to reproduce and investigate the issue with currently owned Compex mPCIe modules for now. Of course we would gladly continue the thread and publish the information and status of our effort on PC Engines forum.

@pietrushnic FYI.

[pietrushnic]

@nicklowe thanks for contribution. We should publish the hardware matrix that we testing and think about investing in above Compex modules.

[gilfrade]

I'm trying to use a wireless card WLE1216V5-20 7A (source) and its detection is a little tricky and bios related. Maybe related to what @nicklowe described.

For example, with bios version v4.0.7 (came by default) the card is only detected with a second soft reboot. Multiple hard reboots does not allow the card to be detected.

With bios version v4.0.11 legacy and later the card is only detected if at bios F10 is pressed and "setup" is selected, it does not matter if new bios settings are saved or not.

Any thoughts? Is this a SeaBios related issue or Coreboot?

By the way download links for v4.0.9 and v4.0.10 are broken from https://pcengines.github.io/#mr-14

[miczyg1]

@gilfrade thank You for Your feedback. Have a look at CHANGELOG we have added some quirk for mPCIe2 port since v4.0.11. It may be influencing the card detection. Could You try v4.0.10 whether it behaves the same as v4.0.7? Also what slot do You use when connecting the card?

It seems like the older release links expired on pcengines site. I would have to ask person responsible for hosting what happened. For now You may download them here:

• apu2_v4.0.9
• apu2_v4.0.10

I would appreciate if You could check it.

[gilfrade]

@miczyg1 thank you for your quick response. I made another round of tests that i included on the anexed file WLE1216V5-20_APU2.zip

The tests where made using APU2 with the card on slot2, all methods fail on slot1. Changing the bios option of forcing mpcie2 clock quirk when available with no change in results. Also tried changing bios options to match the defaults on v4.0.7 but made no difference.

[pietrushnic]

@gilfrade we are a little bit busy with osfc2018 we will take care of that in coming release. Unfortunately, we don't have that card, so probably will rely on WLE{200NX,600VX,900VX} and see if we can improve the situation for all. Please be patient this may take time till v4.8.0.5 or further version. Meanwhile, I have nothing else to offer then using old legacy versions.

[gilfrade]

@pietrushnic i have the following cards WLE{200NX,600VX,900VX,216V5-20,650V5-18}

The cards WLE{200NX,600VX,900VX} have been working great with no issues regarding compatibility with mainboard. The card WLE{650V5-18} have not been fully tested but it is detected and runs normally. The card WLE{216V5-20} is the only with detection issues, when detected i have not encountered any issues running it.

The tests were made with APU2C2, but i also have APU3A2. I am available to help you test bios build changes.

[gilfrade]

Any news about this issue? I can help testing.

[pietrushnic]

@miczyg1 can we provide debug version of v4.8.0.5, @gilfrade any chance you can use pce-fw-builder to build firmware by yourself?

[gilfrade]

@pietrushnic Yes, i can do that.

[pietrushnic]

@gilfrade any luck with building and testing version with verbose logging? Best would be spew level 8 since it is most verbose.

[gilfrade]

@pietrushnic Sorry i was waiting for @miczyg1 answer before proceding. Anyway i tried using pce-fw-builder but it stops when it tries to run "docker run" with error.

./build.sh release v4.8.0.5 apu2
or
./build.sh dev-build `pwd`/release/coreboot apu2

after cloning and downloading docker image it stops at

/bin/bash: /home/coreboot/scripts/pce-fw-builder.sh: Permission denied

I'm using Fedora 28 Workstation. What steps can i use to debug the docker error?

Update: It was a conflict with selinux. Making "sudo setenforce 0" temporary allows the process to continue.

[miczyg1]

@gilfrade have You successfully built the firmware using pce-fw-builder? Any news about WLE{216V5-20}?

[miczyg1]

@gilfrade I have produced debug binary for You:

apu2_v4.8.0.5_debug

This has to be rather PCI initialization problem. I have tried before to figure something out with external PCI devices on apu based on firmware log, but coreboot does not care for non-static PCI devices and does not enable them in early phases (although it does for ethernet controllers). They are later enabled by either SeaBIOS or kernel itself.

Try it and please send me the logs. You may also try to pass amd_iommu=off to kernel cmdline to see if it helps on v4.8.0.3 and later versions.

[miczyg1]

@gilfrade any results?

[gilfrade]

@miczyg1 sorry for the delay, i was waiting for the flash recovery adapter just in case of failure. Here is the bios output with WLE{216V5-20}:

apu2_v4.8.0.5_debug.log

In sum, it did not detect the radio card even with amd_iommu=off. Can you produce a debug bios of v4.0.7? This is the only one that detects the board on a reboot after first boot, maybe we can identify differences.

[miczyg1]

@gilfrade thank You, of course we can try 4.0.7. From the log I can see that coreboot and SeaBIOS both detect a child device on the bridge (PCI 4:0.0) and assign resources, io, memory etc. The PCI ID is 168c:002a which matches the Qualcomm Atheros AR928X. The only thing that bothers me is:

PCI IRQ: Found device 0:02.04 using PIN D
PCI Devfn (0x14) not found in pirq_data table
PCI IRQ: Found device 0:02.05 using PIN A
PCI Devfn (0x15) not found in pirq_data table

I will try to do something about it. For now lets try these two binaries:

Also would You mind sending me also a dmesg output for 4.0.7 both working and not working + 4.8.0.6 working (if hopefully will work) and not working cases?

apu2_v4.8.0.6_debug apu2_v4.0.7_debug

v4.0.7 may have problems with iPXE, however if You have dhcp server set up properly, it may work. v4.0.7 version is a little bit archaic and support very old build procedure, not maintained anymore, so it may not work exactly the same way as release binary.

Also be aware to not flash the SPI recovery dongle. After booting OS, remove the dongle, before flashing.

[gilfrade]

@miczyg1 forgot to mention that i also have a WLE{200NX} in the board mpcie1, this radio has been working properly with every bios version tested. WLE{216V5-20} is in mpcie2.

apu2_v4.0.7_debug.log apu2_v4.8.0.6_debug.log

In sum, in v4.0.7 WLE{216V5-20} is detected on reboot right after first boot although in this debug version fails to load ath10k firmware. In v4.8.0.6 it is not detected.

[gilfrade]

@miczyg1 here is dmesg of stable v4.0.7 and v4.8.0.6_debug

dmesg_v4.0.7.log dmesg_v4.8.0.6_debug.log

[nicklowe]

Any update on this?

[miczyg1]

@gilfrade @nicklowe in the logs I can see that the WLE216V5-20 is not detected by coreboot and/or SeaBIOS at all (except 4.0.7 after reboot) and thus PCIe bridge is not being enabled, resources are not assigned etc. This is a firmware problem. I will think what we can do to solve the problem (probably will send some binaries to You for testing). We do not have this particular WiFi card (we only have WLE200NX which works well), so it might be difficult or just take much time to find the root cause.

[nicklowe]

Hi Michał,

Understood, thanks so much for your efforts here!

As a gift with no obligation or expectations of success on my behalf and purely to try and help out, I have ordered and paid for a WLE1216V5-20 card from compexshop.com to be delivered in your name to the 3mdeb office.

Regards,

Nick

[gilfrade]

@miczyg1 i'm available to help with testing, send me some binaries whenever you need.

[miczyg1]

Hi Nick,

I bow before Your kindness and generosity. We will put in the best effort to achieve positive results with the WLE1216V5-20.

Best regards, Michał

[nicklowe]

Hi Michal,

Please can you let me know if you received the card today? The tracking says it should have been delivered. I just want to check that it has arrived safely! :-)

Cheers,

Nick

[miczyg1]

Hi Nick,

Yes, I have receive the card today. It arrived safely and is already connected for testing. Really appreciate that.

Regards, Michał

[nicklowe]

Hi Michał,

Thanks for looking, hopefully it reproduced!

Best,

Nick

[miczyg1]

@nicklowe yes it reproduces well (at least doesn't work for all firmware versions). I have not tried the lucky 4.0.7 firmware yet

[nicklowe]

Hi Michał,

Thanks for confirming that it reproduces, I am pleased the issue can at least be observed first hand. It's a weird one!

Best,

Nick

[miczyg1]

Dear @nicklowe @gilfrade I guess I have found the root cause of WLE1216V5-20 detection failures.

I have encountered recently weird issues with Quectel EP06 LTE module, which also refused to work on APU2. It turned out that some PCIe slots are not "compatible" with all modules. I mean that modules sometimes require certain signal states on the lines connected to the module. For example in case of Quectel EP06 module, SMBus lines connected to mPCIe slot caused improper operation of the module (only 1 or 0 ttyUSB nodes created instead of 4). When the SMbus lines were pulled up or not connected to the slot, everything worked well.

The same goes for this module. I tried various mPCIe slots connections in many APU board and I have found the one which works perfectly (100% detection across coldboots/reboots with v4.9.0.2 firmware). The configuration the module works for me:

I have compared them to hardware design guide of WLE1216V5-20 and it seems to be most compatible. By compatibility, I mean the number of unused module signals (NC) that are not connected/routed on APU'S mini PCIe slot (on PCB). Unfortunately, the picture shows a slot form APU5. APU2/3/4 do not have such configuration. The lanes that are (or may) disrupting the detection and proper operation are USIM lanes and SMB_DAT, SMB_CLK (according to APU2 schematics page 8) USB lanes are not used too, but they seem to not interfere that much. It would be great to have only the lanes connected which are listed in the hardware design guide but it is impossible if one want s to support variety of modules.

PC Engines tried to keep compatibility with as many modules as possible giving APU users freedom of the module choice.

To sum up, this is not a BIOS issue. Hardware connection with module also influences its operation, sometimes in a bad way like You have experienced. I would advise to contact PC Engines and ask how to solve Your problem. The module will probably never work with current apu2 revisions. I can not tell if they will be willing to design a new revision. It is always a matter of compromise, which modules to support and what not. Each module is different in its design and it is impossible to support all of them. Please keep it in mind when using new, unverified modules or when contacting PC Engines regarding this issue. PC Engines also lists tested modules on their site (see sample configurations -> wifi options).

tl;dr

I still expect some issues like:

[    8.965800] ath10k_pci 0000:01:00.0: failed to fetch board data for bus=pci,bmi-chip-id=0,bmi-board-id=31 from ath10k/QCA9984/hw1.0/board-2.bin
[    8.978779] ath10k_pci 0000:01:00.0: firmware: failed to load ath10k/QCA9984/hw1.0/board.bin (-2)
[    8.987901] ath10k_pci 0000:01:00.0: failed to fetch board data
[    8.993848] ath10k_pci 0000:01:00.0: failed to fetch board file: -2
[    9.000341] ath10k_pci 0000:01:00.0: could not probe fw (-2)

or

[    9.965023] ath10k_pci 0000:01:00.0: failed to wake up device : -110
[    9.968186] ath10k_pci: probe of 0000:01:00.0 failed with error -110

There seems to be a problem related to atheros firmware and the power management of the module. From lspci I see that the module has many capabilities like ASPM L1, which can be enabled in BIOS for the PCI Express port. I will play with it a little to see if it will improve the situation.

Hope I did not make You sleepy with this essay.

Best regards, Michał

[gilfrade]

@miczyg1 your conclusion is that "The module will probably never work with current apu2 revisions" due to disruptions on hardware. Any guess as to why the module works using BIOS v4.0.7 by a second boot and is there a way to improve compatibility by disabling features on BIOS side (likely using lanes you mentioned)?

[miczyg1]

@gilfrade I will right myself a little bit. " The module will probably never work stably with current apu2 revisions".

"the module works using BIOS v4.0.7 by a second boot" - this is not what I consider "working". It just looks more like a mere luck that module is up during PCI enumeration in BIOS. It is even weirder that only this particular version gives some positive results. Have You tried all possible legacy versions? Based on my experiments I proved it is a hardware related problem and 100% detectability (no matter cold boot or warm boot) is a strong proof.

There is almost nothing to do on BIOS side since SMBus is needed by processor for other purposes. What could be done to improve compatibility is to try pulling up SMBus lanes (as it helped with Quectel EP06 - but I have not tested such scenario with WLE1216V5-20) or entirely remove the SMBus wires from the slot. However, all these approaches require risky hardware modification. As a provisory"fix" You could use the tape to cover SMBus pads on the module and try out if it helps. If not, try additionally with USIM or USB signals etc. APU schematics and module connector design are all open in the network. I may also try this taping or if I can use internal pull-ups in the processor. However, I can not promise any improvement with the pull-ups. Small chance, but still I will do whatever I can.

Processor and hardware initialization is not as simple as it sounds. Software will not always be able to fix everything. On such a low level, where capacitance and resistance also matters, one can observe different results with different modules. Each module is designed differently and does not respond in the same time for example. On the second hand, the module hardware design says NC on these particular lanes, but nowhere it is mentioned how the slot should be designed in order to guarantee the proper operation of the module. There is not even a single word in the documentation that unused/NC signals should be left floating. My approach was to eliminate any influence from hardware side before I start blaming BIOS for buggy implementation. You have made the right call to present the issue here, where we solve BIOS-related problems, but in some cases, it just happens to be a hardware fault, not software. We are here to help and solve such problems anyway.

It should be noted that mini PCIe standard allows connecting various signals like PCIe, USB, USIM, SMBus and even USB3.0 signals, depending on needs on the module that is intended for use. There is no guarantee that in such variety of options every module will behave the same way - not even saying "will work". I wish module vendors could design more robust products and be more consistent with the connector design standard.

[gilfrade]

@miczyg1 "You tried all possible legacy versions?" Yes, i anexed a file in the first comments with my results, it does not contain the latest versions. "It just looks more like a mere luck that module is up during PCI enumeration in BIOS", i have a sucess rate of +98% of successfully detect the module in second boot using v4.0.7. I'm not saying this is totally a BIOS problem, your explanation makes sense and is most likely correct, i'm just saying that, by "luck", this BIOS version does something that has a consequence makes the module work in a second boot.

Again, i'm not stating that this is a BIOS problem, just that maybe there's workaround that can be done in BIOS to improve detection success rate, ideally at first boot. Thank you for your help.

[pietrushnic]

@miczyg1 I think we should reconsider what @gilfrade wrote. The first question is - can we get the same results as @gilfrade? If yes, then if we talking about second boot the case may be that OS and its kernel/drivers change the state of the device so it works on second boot. Another idea has controlled the reset of PCIe device or some game with ACPI (forcing some of the D0-D3 states). I'm not sure if those things are rather on the firmware or OS side, but maybe it is worth to try.

Do we have info about OS and kernel/drivers version on which second boot works?

@gilfrade we try to treat each bug according to its business influence and definitely we cannot provide just debugging logs as prove of whole month work. Saying that things may take a little bit of time. I know this bug is here for a long time, but support for a wide variety of modules is very hard, if even possible.

@miczyg1 let's try to consider above ideas in next release cycle and see if we can squeeze fix from some firmware behavior. IMO it rather would not be a clean solution.

[silentcreek]

Hi folks, I'd like to add that there seems to be an issue also with the detection of the Compex WLE600VX module in mainline (but not in legacy).

I just bought a WLE200NX and a WLE600VX module and installed them in my APU2C4 this weekend. My OS is Debian 9 (Stretch) and I have the atheros firmware package installed as well. I was surprised to see that WLE600VX was not detected after I installed both cards (the WLE200NX worked fine right away). I tried (soft) rebooting as well as cold booting, but the card would just not be detected. That was on mainline firmware 4.9.0.1. I then decided to test the legacy firmware 4.0.24 and after flashing that, the card comes up just fine no matter how often I reboot or cold boot the device. I won't have time to dig into this deeper this week as I'm travelling, but I will retry mainline with 4.9.0.3 once I'm back. Nevertheless, I thought I'd give you a heads up as I was under the impression that no issues with this particular card were known so far.

Please further note, the WLE200NX is installed in the center slot while the WLE600VX occupies the first slot (left, if you're looking at the front side of the board facing the status LEDs). I haven't tested yet if it makes a difference when I swap them.

[miczyg1]

@silentcreek we have encountered issues with WLE900VX with v4.9.0.1 on apu2. I assume this is a similar problem and WLE600VX may suffer too. Try v4.9.0.2, should be ok in my opinion.

[silentcreek]

@miczyg1 Thanks, yes, with newer releases the card is recognized. I skipped 4.9.0.2 and went with 4.9.0.3 directly and the card was recognized just fine. I did, however, run into new errors which I just reported here: https://github.com/pcengines/coreboot/issues/285 So, I downgraded to 4.0.25 for now which runs fine.

On a sidenote: The changelog for 4.0.25 on https://pcengines.github.io/ seems off (maybe copied over from 4.0.24?). At least it doesn't match the git log.

[miczyg1]

@gilfrade I have some news about WLE1216V5-20. After performing more tests I came to following results on apu2:

• WLE1216V5-20 does not work with any mainline BIOS version
• WLE1216V5-20 works with v4.0.7 after reboot, but on my apu2 I'm getting kernel panics as soon as I log into the system
• WLE1216V5-20 works with v4.0.25 after reboot (and probably most legacy releases), but on my apu2 I'm getting kernel panics as soon as I log into the system
• tried to cover unused signals with tape - unfortunately, it did not improve the situation
• the card does not work in mPCIe1 at all (possibly because apu2 has inverted PCIe RX lanes)

What is more I have conducted more test on apu3 and apu4, which have a mPCIe1 slot designed for PCIe wifi cards too, however they do not have inverted RX lanes as on apu2. Results I got:

platform / firmware version	coldboot	warmboot (via power button pin)	reboot
apu3 v4.0.25	OK	OK	OK
apu3 v4.9.0.3	OK	OK	OK
apu4 v4.0.25	OK	OK	OK
apu4 v4.9.0.3	OK	OK	OK

The reason I have tested only mPCIe1 is that apu3 and apu4 have no PCIe signals on mPCIe2 (only apu2 has). The card works out of the box without using tape, which proves that PCIe works on the processor as it should. No detection and operation issues, no kernel panics. All tests performed using Debian with kernel 4.14.50.

Concluding my results:

• we may possibly have differences in hardware since I cannot fully reproduce Your results (in your case everything works after detection - in my case I get kernel panics)
• as the module works on other platforms (which are almost identical to apu2), there is not hing left to say it is a hardware issue
• overcoming/workarounding it in BIOS may be very difficult (if not impossible) and not a viable option, as it may break other modules for other apu2 users or consume large amount of time

I have no ways to investigate the hardware on electrical level thus I am out of options to move further for now. If come up with new ideas I will post them here with possibly new results.

UPDATE: Each of the boards have different PE_RST circuit, which may introduce different timings on resets for the modules. I suspect that it may influence the detection. It would explain why the module is seen after reboot for example.

[gilfrade]

@miczyg1 your results are the same as mine except with legacy bios i could not make it work after reboot unless i stopped in bios setup first. I do not have kernel panics and WLE1216V5-20 works properly for several months, i'm using OpenWRT latest. It could be differences in firmware.

I now have an apu3c2 and in will check if i have the same results has you (most likely) and i will probably buy an apu4c2.

I will report again when i have an update. Thanks for all your work.

[miczyg1]

@gilfrade I have been using only release binaries, so there should not be any differences in firmware. It may be a different kernel or even different module. I have found information that WLE1216V5-20 had BMI-ID conflicts with other modules thus I had to use patched board-2.bin firmware for the module. https://www.candelatech.com/ath10k-10.4.php Otherwise, the firmware loading failed giving wrong IDs and could not use the module properly. But the detection was not affected. Sharing my experience just for informational purposes, since we may have tested different modules/platforms. Hardware difference is often a huge difference, believe me.

[ouafnico]

Hi everyone

I've search a day to explain why my wle200nx was not broadcasting any SSID, while the wle600vx on the same APU2C4 was working.

Both cards are installed in the same time.

I was using coreboot 4.9.0.2, and tried 4.9.0.5. Same problem. After downgrading to 4.0.25 it works !

[miczyg1]

Hi @ouafnico ,

1. Have possibly used the module on apu3/4?
2. Is the WLE200NX detected in lspci?
3. Have You tried amd_iommu=off in v4.9.0.x? Like here: https://github.com/pcengines/coreboot/issues/206

[riptidewave93]

Sorry to revive an old issue, but I just found this thread after dealing with issues getting my WLE1216V5-20 to be seen on my APU2C4. I am curious @miczyg1, does the PE_RST circuit stay the same in the APU2D4 and APU2E4? I would really love to have a board that can run both the WLE1216V5-20 and WLE1216V2-20, and since the APU2 series is the only one with PCIe wired up to both mPCIe slots, it seems to be the only option for these cards.

[miczyg1]

@riptidewave93 have a look at https://github.com/pcengines/coreboot/blob/release/CHANGELOG.md#v41105---2020-03-27

In the upcoming few days we will release v4.11.0.5 that implements additional PCIe reset logic using GPIOs (PE_RSTx signals) on apu2. As far as I have tested it doesn't cause regression in PCIe modules detection in the default testing configuration in our office, but I have been unable to test with WLE1216* modules (due to covid-19 I am limiting visits to the office and did not switch the modules to check it yet, working remotely now most of the time). I have high expectations about this change and also hope to get this module working as it should. I will post an update here when I will have an opportunity to test WLE1216 on apu2.

As for the PE_RST circuit, there have been some changes since revision D as you may compare on the schematics between APU2C vs APU2D and APU2E*:

• https://www.pcengines.ch/schema/apu2c.pdf
• https://www.pcengines.ch/schema/apu2d.pdf
• https://www.pcengines.ch/schema/apu2e.pdf

There is an additional resistor in the mPCIe2 slot reset circuit since revision D.

[riptidewave93]

Hello @miczyg1,

Thank you very much for the update. If you have a build of v4.11.0.5 laying around, id love to help test it quick! As for the PE_RST circuit changes in the APU2D and newer, do you believe this will have any impact on the stability of the WLE1216 modules? I guess I am asking, is it worth replacing my APU2C4 with an APU2E4 if I want to use the WLE1216 modules? (given if the latest patches help get the cards working correctly)

EDIT: So I got a build of v4.11.0.5 going using pce-fw-builder, but sadly my WLE1216* modules are still undetected by OpenWrt. Guess I will wait and see how your testing goes. For all I know, I compiled it incorrectly; or so I hope. :crossed_fingers:

[riptidewave93]

Hello,

I see v4.11.0.5 is out, so I decided to test a few of the wireless modules I have laying around with this latest build. Below you can find the results of my testing. Note the below is from my APU2C4 board.

V4.11.0.4	Wireless Module	mPCIe 1	mPCIe 2
WLE200NX	:heavy_check_mark:	:heavy_check_mark:
WLE600VX	:heavy_check_mark:	:heavy_check_mark:
WLE900VX	:heavy_check_mark:	:heavy_check_mark:
WLE1216V5-20	:x:	:x:

V4.11.0.5	Wireless Module	mPCIe 1	mPCIe 2
WLE200NX	:heavy_check_mark:	:x:
WLE600VX	:heavy_check_mark:	:x:
WLE900VX	:heavy_check_mark:	:x:
WLE1216V5-20	:x:	:x:

[miczyg1]

@riptidewave93 thank you for your results. It seems like we broke mPCIe2 slot. I am looking into it now.

id love to help test it quick! I hope your words are still relevant. I see you have all modules at hand so I would like to "take an advantage" of that :) I will produce another binary with a small change to PCIe clocks, so maybe it could help.

[riptidewave93]

@miczyg1 Sure thing, feel free to share anything you would like me to test. :)

[miczyg1]

@riptidewave93 https://cloud.3mdeb.com/index.php/s/HFRNLag4Swi9aXC