User:Dafda-Rohit

Hi im dafda Rohit from :-india my St-gujarat city kalsari Gir

computer end software hardware cctv other install Android java c++ C# computer hacking social site Contact end other contry twitter Instagram Facebook any other hack

It probably goes without saying that hardware hackers were excited when the Raspberry Pi 4 was announced, but it wasn’t just because there was a new entry into everyone’s favorite line of Linux SBCs. The new Pi offered a number of compelling hardware upgrades, including an onboard PCI-Express interface. The only problem was that the PCIe interface was dedicated to the USB 3.0 controller; but that’s nothing a hot-air rework station couldn’t fix.

We’ve previously seen steady-handed hackers remove the USB 3.0 controller on the Pi 4 to connect various PCIe devices with somewhat mixed results, but [Colin Riley] has raised the bar by successfully getting a PCIe multiplier board working with the diminutive Linux computer. While there are still some software kinks to work out, the results are very promising and he already has a few devices working.

Getting that first PCIe port added to the Pi 4 is already fairly well understood, so [Colin] just had to follow the example set by hackers such as [Tomasz Mloduchowski]. Sure enough, when he plugged the port multiplier board in (after a bit of what he refers to as “professional wiggling”), the appropriate entry showed up in lspci.

But there was a problem. While the port multiplier board was recognized by the kernel, nothing he plugged into it showed up. Checking the kernel logs, he found messages relating to bus conflicts, and one that seemed especially important: “devices behind bridge are unusable because [bus 02] cannot be assigned for them“. To make a long story short, it turns out that the Raspbian kernel is specifically configured to only allow a single PCI bus.

Fortunately, it’s an easy fix once you know what the problem is. Using the “Device Tree Compiler” tool, [Colin] was able to edit the Raspbian Device Tree file and change the PCI “bus-range” variable from <0x0 0x1> to <0x0 0xff>. From there, it was just a matter of plugging in different devices and seeing what works. Simple things such as USB controllers were no problem, but getting ARM Linux support for the NVIDIA GTX 1060 he tried will have to be a topic for another day.

[Thanks to Paulie for the tip.] Posted in hardware, Raspberry PiTagged Device Tree, multiplier, pci express, PCIe, Raspberry Pi 4, Raspbian Post navigation ← Ham Radio Company Wins Big High Voltage Protects Low Denominations → Advertisement 13 thoughts on “PCIe Multiplier Expands Raspberry Pi 4 Possibilities”

   Xeon says:	
   September 5, 2019 at 10:15 pm

   Someone should create a port to fit in place of the chip so doing this mod can be a breeze.
   Report comment
   Reply
       Nadia Mayer says:	
       September 5, 2019 at 11:10 pm

       Just connect it to the USB 3 port so you can use cable card thing its on the same chip pad
       Report comment
       Reply
           onebiozz says:	
           September 6, 2019 at 12:24 am

           It would be nice to see a drop in jumper PCB for it
           Report comment
           Reply
   ScriptGiddy says:	
   September 5, 2019 at 10:19 pm

   How far we’ve come…
   Report comment
   Reply
   This hack sucks says:	
   September 5, 2019 at 10:19 pm

   I guess the next step would be adding extra RAM to the Raspi, but the final step is going to be to have a plain old motherboard with an ARM socket in it.
   Report comment
   Reply
   hybls says:	
   September 6, 2019 at 12:15 am

   arm drivers for AMD and Nvidia graphics cards would change the game. you could implement the new usb 4 spec on a future phone (or license a future less power hungry thunderbolt) and have it run an external graphics card and monitor. An ultra short range ghz transceiver could even be placed within a wireless charging coil so it connects and powers as soon as you set your phone down. One can only dream…
   Report comment
   Reply
       mm0zct says:	
       September 6, 2019 at 1:45 am

       Nvidia’s 710 works fine connected to our ARM virtual platforms via pcie-pasthrough, you have to modify the buildroot config for nouveau to persuade it that Aarch64 is a valid target, but then it builds and works just fine with Mesa. I’ve run the glx-gears test application and played GLTron on it. This is basically the same as the Pi setup if you’re using an Aarch64 Pi kernel.
       Report comment
       Reply
   David says:	
   September 6, 2019 at 12:30 am

   How long before the interface is actually equivalent from the factory.
   Report comment
   Reply
   JKW says:	
   September 6, 2019 at 12:57 am

   Is there no compute module for RPi4 where PCIe breakout could be achieved easier?
   Report comment
   Reply
       Greg says:	
       September 6, 2019 at 1:36 am

       no, there is not.
       Report comment
       Reply
       Paulie says:	
       September 6, 2019 at 1:55 am

       Pi4 Compute module in its present form factor wouldn’t have enough pins on the edge connector to break out PCIe. So edge connector plus an additional part for PCIe becomes harder to manufacture,& less robust in practice.
       I predict that first version won’t have PCIe, and a CM4+ may not be viable anyway.
       Report comment
       Reply
   johnny_programmer says:	
   September 6, 2019 at 1:15 am

   So does that mean you could replace the mmc card with a fast hdd or ssd? Does that mean you could run windows 10?….
   Report comment
   Reply
       This hack sucks says:	
       September 6, 2019 at 2:53 am

       You would still need the memory card to boot. Then you would need to do a pcie/sata initialization routine that fetches the first 512 out of a defined SATA hard disk. After that, I think that the OS would need to be modified in order to be able to pull more data from the SATA drives, using this setup.

       I guess it would be much easier to pull the first 1 GB of data into RAM, and boot the OS from there. It would he much easier to implement a trivial driver inside the OS that could acknowledge the existence of a SATA controller board, inside a PCIe board.

       Most of this stuff gets done using the chipset inside the motherboard, but, since you got no chipset, you must implement this manually, and it would be much slower than the current motherboards approach.
       Report comment
       Reply

User:Dafda-Rohit

Content Disclaimer