Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PCI Express on the Raspberry Pi 4

mloduchowski.com

Post reply on HN
Print view View original

51–60 of 166 posts

Re: PCI Express on the Raspberry Pi 4

#51

Post by userbinator »

noobermin wrote: post #32

Now this is the content I come to HN for. A serious hack just days after the 4 was released. Kudos to the OP. I envy people like OP for their tenacity. I barely have time to follow what's happening in IT, much less get ahead of the pack in doing cools hacks like this.

On the other hand, the fact that the RPi ecosystem remains notoriously proprietary (even the USB controller is a bastard variant that has next to no documentation --- of all the ones available, they had to choose that one) continues to be disappointing.

I definitely like this sort of hack, but such hacks with documentation already available (and doing more than documented, basically) are certainly preferable.

Re: PCI Express on the Raspberry Pi 4

#52

Post by jamesfmilne »

Jonnax wrote: post #2

That's really cool. I'm curious, would it be possible to use a modern GPU (running at 1x) on an ARM based board? Would the open source drivers that are part of the Kernel work out the box on ARM?

NVIDIA drivers might even work too

Linux 32-bit ARM drivers

https://www.nvidia.co.uk/Download/driverResults.aspx/137468/...

Re: PCI Express on the Raspberry Pi 4

#53

Post by HeWhoLurksLate »

mkesper wrote: post #22
segfaultbuserr wrote: post #5

It looks like an unreliable modification. Running a GHz-level interface with jumpers is almost impossible to control the impedance, it's a cool Proof-of-Concept though. But is it possible to bring the project to the next level? Is it possible to make a daughterboard with QFN connector? If so, one can make a pin-compatible daughterboard with an extension connector. To use it, just desolder the USB chip and solder a ne…

Maybe a new raspberry compute module ( https://www.raspberrypi.org/blog/raspberry-pi-compute-module... ) featuring PCIe could be implemented?

Oh heck yeah, that'd be amazing. I'm unfamiliar with this- do the compute modules have any sequential unused pins on them?

Re: PCI Express on the Raspberry Pi 4

#54

Post by Legogris »

megous wrote: post #44
yetihehe wrote: post #3

Hmm, how about using this for fast interconnect for making rpi clusters?

You'll lose fast storage. So you end up with devices with 40MB/s uSD cards and multi-gigabit interconnect.

You could just use an USB device for higher throughput. The Sandisk Extreme Go, for example, is basically a small SSD in a USB drive form-factor.

Re: PCI Express on the Raspberry Pi 4

#55

Post by elFarto »

peterburkimsher wrote: post #25

Nice work! Would this be compatible with an M.2 to PCIe adaptor? [1] Being able to attach an Intel 660P and get 2 TB of fast SSD storage on a Raspberry Pi would be sweet. [1] https://www.amazon.com/EZDIY-FAB-Express-Adapter-Support-221...

Technically yes, but it's only a PCIe 1x Gen2 slot, so only 500MB/s of bandwidth (4x Gen3 is ~4GB/s). You'd be better off with a USB 3.0 to M.2 adapter.

Re: PCI Express on the Raspberry Pi 4

#56

Post by girvo »

Legogris wrote: post #54
megous wrote: post #44

Earlier quoted context omitted.

You'll lose fast storage. So you end up with devices with 40MB/s uSD cards and multi-gigabit interconnect.

You could just use an USB device for higher throughput. The Sandisk Extreme Go, for example, is basically a small SSD in a USB drive form-factor.

If I’m reading it right, don’t you give up USB to get this PCIe access?

Re: PCI Express on the Raspberry Pi 4

#57

Post by floatboth »

qdot_me wrote: post #6
Jonnax wrote: post #2

That's really cool. I'm curious, would it be possible to use a modern GPU (running at 1x) on an ARM based board? Would the open source drivers that are part of the Kernel work out the box on ARM?

Hack’s creator here - it’s on my list of things to try. GPUs are notoriously hard to get to work on non-intel, having tried to get a few up on Alpha and Itaniums in the past. VideoBIOS expects to run and expects a well behaving Intel CPU to do the power-up. That said X can sometimes emulate these quite well. On ARM we’d also run into alignment issues and likely other quirks - but in principle...

VBIOS is often not necessary for running a GPU in the OS. The amdgpu driver can POST a GPU by itself just fine.

Still… X86EmulatorPkg allows running an amd64 VBIOS in UEFI on an aarch64 machine :)

AFAIK the bigger problem on embedded boards is half assed Synopsys Designware host controllers. I have a Radeon running on my Marvell MACCHIATObin, on FreeBSD even. But from what I've heard the Rockchip RK3399 has a worse version of the controller, and people trying GPUs on the ROCKPro64 saw errors related to not large enough BAR space or something.

UPD: yeah, someone in the thread mentioned BAR space issues wrt NXP i.MX SoCs, that's probably what's happening on Rockchip. Would be amazing if the Broadcom chip in the Pi turns out to be the one with enough BAR space! :D

Re: PCI Express on the Raspberry Pi 4

#58

Post by floatboth »

jchw wrote: post #17
qdot_me wrote: post #14

Earlier quoted context omitted.

It’s all, cough, implementation dependent. You can run two VideoBIOS implementations, and chances are only one will install an int10h handler, but both will set up the registers and whatnot in the GPUs. My AMD TAHITIs for instance need VideoBIOS to start some form of thermal management loop - otherwise they just run full-throttle on the fan. Then whichever card prevails (BIOS has the ability to select the initializat…

Thanks for the information. I’ve been really curious about this with the incoming ARM dev boards that have full PCI-e edge connectors. Pretty fascinating that X11 of all things is dealing with Video BIOS initialization, though. The sheer amount of functionality that was overloaded into X...

You don't need X, and I wouldn't assume its remnants of userspace mode setting would work on non-x86.

The amdgpu kernel driver POSTs the GPUs when loaded just fine! I run an RX 480 on a MACCHIATObin with FreeBSD and Wayland only :)

Plus, there are two ways to get the GPU in UEFI already – X86EmulatorPkg and native aarch64 GOP driver builds provided by AMD.

Re: PCI Express on the Raspberry Pi 4

#59

Post by LIV2 »

userbinator wrote: post #50
kees99 wrote: post #30

Earlier quoted context omitted.

It looks like an unreliable modification. PCIe is surprisingly robust at short lengths. For example, [NanoPi_M4] has two lanes of PCIe coming to the daughterboards via old-school 0.1" connector. Something that many electrical engineers would cringe at, and yet - it works rather reliably. [NanoPi_M4] http://wiki.friendlyarm.com/wiki/index.php/NanoPi_M4#Layout

Exactly, the PCIe reference clock is "only" 100MHz. USB 2.0 runs at 480MHz and motherboards have used 0.1" headers for them since the beginning.

While the ref clock is only 100MHz the data rate of PCI Express is much higher, it's a serial bus pushing multiple gigabits a second https://electronics.stackexchange.com/a/259002

Re: PCI Express on the Raspberry Pi 4

#60

Post by floatboth »

pm215 wrote: post #13
qdot_me wrote: post #6

Earlier quoted context omitted.

Hack’s creator here - it’s on my list of things to try. GPUs are notoriously hard to get to work on non-intel, having tried to get a few up on Alpha and Itaniums in the past. VideoBIOS expects to run and expects a well behaving Intel CPU to do the power-up. That said X can sometimes emulate these quite well. On ARM we’d also run into alignment issues and likely other quirks - but in principle...

People have got at least some cards working on server-class arm setups. On the other hand I think they might be using the 'emulate x86 uefi rom in an arm uefi system' hack, so there might be more effort required on a non-uefi setup. Still, it should have shaken out most of the alignment and memory-cacheability-attibutes issues already, hopefully.

Yep, the "hack" (X86EmulatorPkg) allows running the card in the UEFI out of the box. AMD also provides native aarch64 builds of their UEFI GOP driver though. And none of this is necessary for running the GPU in the OS – amdgpu POSTs the GPU just fine.

> memory-cacheability-attibutes issues

Recently I've added aarch64 support to FreeBSD's port of the DRM/KMS drivers :) Took a couple hours to realize that our implementations of Linux's mapping functions used normal uncacheable memory instead of device memory – fixing that stopped the hangs on driver load and allowed everything to work.

Then there was some corruption on the screen – our drm-kms is from Linux 5.0 for now, and I've had to cherry-pick a fix that only landed in 5.1 I think: https://patchwork.kernel.org/patch/10778815/

Post reply on HN