You cannot force a x1 connection unless you cut off all the other lanes. The laptop and the board decide on the possible link speed during PCIe training. You can only limit it down to x4 if you configure the board to do 1X4 in the configurator.
Did you perhaps try downgrading to the same BIOS version as me? I’m on v3.07 as I’ve managed to get PEX_RST to work on it. It was just a matter of resetting the BIOS settings and doing a battery disconnect inside the BIOS. Then just hold the power button down after unplugging power to completely drain the power to the embedded controller.
I will try to upgrade back up to v4.03 when I get some time to see the state of that APU GPIO. Does anyone have an idea how to read that specific GPIO from inside an OS like Linux?
Yes might be worth a try. This feels like such a fundamental issue though with PEX_RST - do you not think if it was more widespread many other projects would be experiencing similar difficulties? Or are you/we the first people to be messing around with PCIE lanes as third parties and hence the only ones affected?
I am really unsure what the actual root cause of the issue is. I didn’t notice anyone having similar issues with dGPU modules and they use the same PEX_RST signal. I did also send my board to a tester nearby so they should be able to also see if they get the same issue with PEX_RST on their end sometime next week.
Regarding “APU GPIO: 0xFED815A0” for the PEX_RST output.
The AMD documents that are public, don’t have 15A0 actually in a document so I don’t know what each bit does.
So for “00 00 A4 00”, I don’t know what that value means.
Purpose being, it might be useful to be able to switch the PEX_RST output manually to high / low for test purposes.
Still no life even with 3.07. My multimeter has run out of battery so I can’t test any more tonight, but I’d like to check out the PWR_EN and TH_OVERT lines. These are supposed to be the only abnormal nets outside of the PCIE standard, so they seem like the best place to check first.
PWR_EN seems suspiciously low, and the others both seem a bit less than what I might expect at 3.3v.
I’ve searched through the whole MXM spec though and can’t find any reference to how high PWR_EN should be. If nobody stops me I’ll try pulling this up to 3.3v?
Does anyone know whether TH_OVERT, (Thermal shutdown), pulls high for on or high for off?
@catastrophic - I’m reading funny voltages on PWR_EN and SMBCLK lines at 1.7v. Everything else seems to be 3.3V nominal, but I’m nervous about pulling up PWR_EN if the 16 is actually designed to work at 1.8. Maybe @Filip if you’ve got any knowledge about how your board behaves?
Aside from this, I’ve been looking at other laptop schematics, which seem to have PRSNT pulled up to 3.3v, which I’ll try next.
PWR_EN is powered directly from a 1.8V GPIO on the APU. So yes you are correct, do not pull high to 3.3V.
As a general statement this pin is tied to the internal GPU dynamic power control logic in the bios. So I am not sure if this will work with a random 3rd party GPU. (I would assume it does not). Eg AMD smart switch/hybrid graphics mode which can fully power on/off the GPU from the GPU vendors driver. the bios code is checking for the PCIE ID of our GPU to enable this feature.
The dual SSD power behavior is totally different than the GPU behavior, so this mode is only enabled if dual_ssd device is configured in the EEPROM descriptor (and uses different pins, GPIO0 and GPIO1). I would suggest trying to use the generic PCIE device instead. Since 3rd party GPUs are probably not going to work with hybrid graphics support in the driver.
When you are asking about the i2c bus voltages, which bus are you referring to?
Had a suggestion from WiFi-Cable to add DC blocking capacitors to the PCIE RX lines. By far the most insane board repair I’ve ever done. Will test now. Also tied PCIE SW to ground.
Just bought a PCIE to MXM adapter to see whether this MXM card is still working. It’s not getting hot any more.
There are still a few loose ends that need to be tied up, but I’m still at a loss as to what’s missing. Through a bit of SMD rework magic I’ve fixed the PRSNT pin to be connected through a 10k resistor to 3.3v, as listed in this leaked CLEVO MXM schematic, but it doesn’t seem to have helped. All the connectinons have now been continuity checked and seem good. I should mention that I’ve gone back to testing with the V0.2 iteration as, (I believe it was Filip?) explained that TX and RX pairs are actually interchangable.
Yup that was me. You can swap the positive and negative however you want. You still have to connect lanes in the correct order (0 to 0, 1 to 1…etc), but swapping the positive and negative does not matter as PCIe can handle it since its in the required part of the spec. My OCuLink board also works fine even though I did that to multiple pairs to make routing easier.
I’m doing a v4! We’re going to break out every pin, both from the interconnector and also the mxm connector. More importantly, I’m also going to get it assembled by JLCPCB to cancel any chance of it being an assembly error.
It might be a while before I finish the new design, but here’s an initial changelog:
Tying PCIE_SW to ground. This seems to be suggested
Adding DC blocking capacitors on PCIE RX lines, (thanks WifiCable)
Adding a 10k resistor to 3.3v on the PRSNT_RIGHT pin, (and maybe left as well for good measure).
I’ll give an update when the boards are designed, and another when they’re on their way.
@Joe_Shapiro
When you “break out every pin”, what do you mean?
Just some ideas.
It might be easier to make up your own MXM PCB, that fits in the MXM slot. Then put breakouts on the MXM PCB. Maybe put an Oculink connector on the MXM PCB, so you can connect it to an eGPU bay, and at least see if the PCIe bits are working, before using a real MXM board.
The test MXM PCB might also be useful, for QA testing future boards.
