Telephony cards (Sangoma/Digium) would be interesting to try as well, though if you were trying to run FXS ports you would need an additional cable and PSU to supply 12V to the card.
Raspberry Pi PCIe Devices
21–30 of 61 posts
Re: Raspberry Pi PCIe Devices
#22IMHO PCIe (and SDRAM) should be the only interface exposed by a modern CPU. On-board graphics, audio and NICs usually are shitty anyway. SATA is not relevant any more - we better plug an NVMe SSD into PCIe (or get a controller if actually needed). Full USB-C (or ongoing USB-4) means Thunderbolt which is PCIe. Why waste silicon on anything but PCIe then?
> On-board graphics, audio and NICs usually are shitty anyway. Onboard graphics, audio and NICs are perfectly functional and more than enough for most people. Both in work environments and at homes. They've not been in a shitty category for years now. They won't break any records, but they will display websites at high resolution, play clear music, and provide more bandwidth than the link to the internet can handle.…
I really love the pushback here. Yes how awesome it is you are privileged enough to always be able to acquire the best of the best and look down on other "inferior" devices.
But 99% of the rest of us just need things that work and allow us access to good performance.
Re: Raspberry Pi PCIe Devices
#23IMHO PCIe (and SDRAM) should be the only interface exposed by a modern CPU. On-board graphics, audio and NICs usually are shitty anyway. SATA is not relevant any more - we better plug an NVMe SSD into PCIe (or get a controller if actually needed). Full USB-C (or ongoing USB-4) means Thunderbolt which is PCIe. Why waste silicon on anything but PCIe then?
In many cases, these all can use the same pins anyway. Like on some NXP SoCs I've worked with, you just had a bunch of SerDes lanes that could be assigned to any number of functionalities (SATA, SGMII, PCIe, etc.).
Re: Raspberry Pi PCIe Devices
#24IMHO PCIe (and SDRAM) should be the only interface exposed by a modern CPU. On-board graphics, audio and NICs usually are shitty anyway. SATA is not relevant any more - we better plug an NVMe SSD into PCIe (or get a controller if actually needed). Full USB-C (or ongoing USB-4) means Thunderbolt which is PCIe. Why waste silicon on anything but PCIe then?
> Why waste silicon on anything but PCIe then?
Power. PCIe is a fairly power hungry link. On-die parallel connections are incomparably more efficient.
Special low power links like MIPI PHYs also have their place.
USB is high enough speed that you will get quite a bit of overhead from USB>PCI>memory route, and back.
Audio is a particular pita, network too needs as close, and direct as possible connection to the CPU to get maximum performance.
Re: Raspberry Pi PCIe Devices
#25Graphics cards presumably need an external power supply?
Yes; thus the testing of the powered external 16x risers (see the last section of the cards).
Re: Raspberry Pi PCIe Devices
#26Earlier quoted context omitted.
Follow https://github.com/geerlingguy/raspberry-pi-pcie-devices/iss... for progress. You can't boot directly from the SSD without a microSD card, but it (or SATA support for boot) may come soon... just a question of priorities for the Pi Engineering team.
Do you happen to know if booting from the SSD is limited by the closed source bits of the Pi system or is this an effort the open source community can possibly contribute?
Closed source firmware bits, unfortunately.
Re: Raspberry Pi PCIe Devices
#27IMHO PCIe (and SDRAM) should be the only interface exposed by a modern CPU. On-board graphics, audio and NICs usually are shitty anyway. SATA is not relevant any more - we better plug an NVMe SSD into PCIe (or get a controller if actually needed). Full USB-C (or ongoing USB-4) means Thunderbolt which is PCIe. Why waste silicon on anything but PCIe then?
Other than the integrated graphics that are directly part of modern Intel CPUs, everything else you mention is typically internally connected by PCI-e. Onboard USB ports lead to a controller which talks to the CPU via PCI-e, for example.
PCI-e lanes are a limited resource on a CPU and really fast. Dedicating one to a keyboard, for example, is probably inefficient.
I have heard (don't know too much about it) some Intel NICs are able to place network packets right in the CPUs cache for maximum speed, this probably can't be done via PCI-e.
Re: Raspberry Pi PCIe Devices
#28My first thought was "can you boot from a PCIe SSD?" (looks like the answer is "no" from what I see). I wish there was a RPi with 16GB or 32GB of storage soldered to the board. Where I work we're using Raspberry Pi devices for industrial use and corruption of/wearing out the microSD card has been something we've wondered about. We could just buy premium microSD cards but having a "proper" SSD soldered to the board would be very helpful as well.
Re: Raspberry Pi PCIe Devices
#29Earlier quoted context omitted.
Follow https://github.com/geerlingguy/raspberry-pi-pcie-devices/iss... for progress. You can't boot directly from the SSD without a microSD card, but it (or SATA support for boot) may come soon... just a question of priorities for the Pi Engineering team.
Do you happen to know if booting from the SSD is limited by the closed source bits of the Pi system or is this an effort the open source community can possibly contribute?
its mostly that the bootloader has to be patched to see the devices, this is no easy feat as it would bloat the bootloader pretty hard. a chain boot of MicroSD to SSD is best at this time.
Re: Raspberry Pi PCIe Devices
#30My first thought was "can you boot from a PCIe SSD?" (looks like the answer is "no" from what I see). I wish there was a RPi with 16GB or 32GB of storage soldered to the board. Where I work we're using Raspberry Pi devices for industrial use and corruption of/wearing out the microSD card has been something we've wondered about. We could just buy premium microSD cards but having a "proper" SSD soldered to the board wo…
There's the compute module...32GB of eMMC is an option.
https://www.raspberrypi.org/products/compute-module-4/?varia...