PCIe power-draw issue

[soulllink]

I was asked to post this here from youtube.

@Jeff Geerling i think you need other type of PCIe extension cable. The type that support separate power source from separate PSU. Like, try "pcie riser mining" on Ebay or Aliexpress, they got up to 6 pin power supply support, you need at least 4 "molex" pins. GPU uses own 12volt to 5volt buck converter to self initialization. And yes, PCIe have 12 volt rail (pinouts.ru/visual/gen/pci_express.jpg), but on initialization it took significant amount, i'm not sure than Raspberry PC CM4 IO board is rated to 75W power consumption on PCIe lane. While i checked the datasheet: datasheets.raspberrypi.org/cm4/cm4-datasheet.pdf i'm not sure that this system could provide enough power from it's source. Even if in your testing you achieved actual positive result — GPU device drivers will crush under FUBAR circumstances, because not enough power.

for this a got a little bit of feedback from @nowrd2xpln youtube-user:

IMO this is not a PCIe cable issue. Nor do I think it is power related. I won’t rule it out but It can be possible that the carrier board isn’t supplying enough power to drive the board but it is unlikely because the gfx board is able to power up, run it’s firmware to setup the pci config space for the Linux PCIe subsystem system to read from and begin to make an attempt to run the Linux drivers init sequence (or entry point) but as the logs show, it’s clearly showing the the Linux driver is experiencing some kind of failure during the initialization process. This can be for any number of reasons. In order to figure out why it’s failing the Linux driver code should be reviewed at the point of failure possibly going as far as rebuilding the Linux driver and turning on debug print statements, increasing it’s verbosity level of debug statements, or going as far and adding custom debug statements to find out what, and why, failure is occurring.

The quick and easy answer why it’s not working is because the vendors who make the gfx card DO NOT SUPPORT their card for the raspberry pi and the reason why the won’t support it is because gfx vendors wouldn’t generate any income from it. There is no financial incentive to dedicate time and resources to support development in getting the Linux driver for the raspberry pi to work. For company to add support there would have to be some guarantee that every single person that buys a raspberry pi also buy their gfx card.

I’m a firmware and embedded systems engineer who develops firmware and Linux device drivers for Enterprise Datacenter Hardware. Btw first time watching your video and I enjoyed it a lot. I commend you for going as far as you did down the rabbit hole. It takes a lot of grit. I know cuz I do this on a daily basis for work.

I address it like this:

@nowrd2xpln there is still quite a few problems with that. First of all it's not very good idea to test something when you got obvious point of failure. Second, we got ARM CPU that consumes power from 5.1v ~3amp PSU that peak 18W, plus we got 5v to 12v back converter to provide PCIe power that is not 100% efficient, plus GPU got 12v to 5v converter to provide 5v for self initialization, plus we got GPU power phases that is also not 100% efficient and on low end boards is less efficient than on top tier, plus we got GPU silicon that is also provide resistance and low tier silicon have highest voltage requirements than top tier binding. And so on and so on. Usually GPU initialization consumes huge amount of power that why i initially wrote about "75W rated" and not just "75W required". I'm still not quite sure about possibility of using GPU with Raspberry Pi, because GPU bios is actually made to work only in x86-IBM_compatible_system and uses Message Signaled Interrupts or more advanced, but not all ARM based processors support GIC with MSI, it's introduced only in GICv3 and also required interrupt handling to work properly, but i have no idea ho deep it's integrated with GPU firmware. Technically Raspberry Pi 4 should have GICv3, because it's uses Cortex-A72, datasheet that i found wenku.baidu.com/view/9ce1f3558f9951e79b89680203d8ce2f006665e7.html?re=view

Fortunately there is one company that created own architecture, MCST — they develop own CPU and system architecture from scratch, but they use OWN linux kernel, advanced translation plus support only AMD GPU.

This is a type of riser that i'm talking about. it should be connected to a PSU, like a standard ATX or similar, to make it work you probably will need to use "paper clip trick".

[geerlingguy]

Heh, it's funny you mention that: I've been doing a bit of testing with three different power supplies (AC to 4-pin molex x2, and one full on 600W PSU), and I have tried both a powered riser (PCE164P-N03 VER 006) and an IO Crest powered PCIe switch, and both have some weird quirks that make me question my sanity.

Anyways, I'm mostly doing power debugging over in https://github.com/geerlingguy/raspberry-pi-pcie-devices/issues/18#issuecomment-724148340 — but I'll also be testing different power solutions again with all the GPUs to see if it makes any difference. Having a PSU is a blessing and a curse. The 'jumper to keep power on' is annoying ,as is the fact that suddenly my entire desk is taken up by a giant PSU + tons of power cables :D

Thanks for posting this info here, as it's good for reference. Just going to close this issue out and redirect any future power-related discussion to particular cards.

I might do an episode on power in general, though. This whole project's theme is kind of "the Pi was never designed for any of this stuff—but I'm gonna do it anyways!"