Difference between revisions of "ROCKPro64 Hardware compatibility"
(→USB hardware =: typo) |
(fixes) |
||
| Line 61: | Line 61: | ||
|} | |} | ||
== USB hardware == | === USB hardware === | ||
{| class="wikitable sortable" | {| class="wikitable sortable" | ||
| Line 84: | Line 84: | ||
|} | |} | ||
== Limitations == | |||
=== Older firmware overwrites actively used memory === | |||
Some people get system freeze when: | Some people get system freeze when: | ||
| Line 119: | Line 119: | ||
sync | sync | ||
=== PCIe Controller Hardware Error Handling Bug === | |||
There is an issue with the rk3399 pcie controller that is currently unmitigated: | There is an issue with the rk3399 pcie controller that is currently unmitigated: | ||
| Line 130: | Line 130: | ||
The error type is determined by which cpu cluster handles the message. | The error type is determined by which cpu cluster handles the message. | ||
=== Virtualization === | |||
The PCIe controller on the rk3399 is not behind an IOMMU. This means it is not possible to safely pass through PCIe devices to a virtual machine. | The PCIe controller on the rk3399 is not behind an IOMMU. This means it is not possible to safely pass through PCIe devices to a virtual machine. | ||
Revision as of 01:35, 16 March 2023
Hardware accessory compatibility for the ROCKPro64. Please contribute to the hardware compatibility page, which lists hardware which has been tested with the rockpro64, whether successful or not.
Hardware compatibility
PCIe devices
| Type | Make/Model | Hardware IDs | Kernel | Result | Notes | |
|---|---|---|---|---|---|---|
| NIC | Intel I350 Dual Port | Mainline-5.4 | good | SR-IOV fails | ||
| NIC | Intel I350 Quad Port | ? | ||||
| NIC | Intel X520 Dual Port | 8086:10fb | Mainline-5.6 | good | SR-IOV fails | |
| NIC | Intel X550-T2 Dual Port | 8086:1563 | 5.15.0-trunk-arm64 (Debian) | good | netperf throughput in FW mode, 20 streams: between 4136-6613mb/s across use cases. | |
| NIC | Intel 82571EB Dual Port (HP NC360T) | Mainline-5.6 | crash | kernel crash on boot | ||
| NIC | Intel 82575/82576 | 8086:1521 | OpenWrt 21.02-rc1 ; 5.4.111-1 | good | opkg: kmod-igb ; OpenWrt 21.02-rc1 5.4.111-1 ; ~92.8 KB ; Kernel modules for Intel(R) 82575/82576 PCI-Express Gigabit Ethernet adapters. | |
| NIC | Aquantia 10GBps AQC107 | 1d6a:07b1 | Mainline 5.16 | good | Works perfectly out of the box. | |
| GPU | nVidia GTX-645 | Mainline-5.4 | crash | BAR size too small, triggers PCIe error handling bug | ||
| PCIe Switch | PCIE-EUX1-04 Ver.002 | Mainline-5.4 | good | |||
| SATA Controller | ASM1062 4-Port | Mainline-5.6 | good | tested only with one disk attached | ||
| SATA Controller | ASM1062 (rev 02) 4-Port | 1d87:0100 | Ayufan-4.4.190 | good | tested with four disks, 3 in raid 5 | |
| SATA Controller | IOCrest (Same as Syba?) SI-PEX40063 4-port, Marvell 88SE9235 chip | 1b4b:9235 | Debian unstable 5.7, 5.8 | good | Tested with two disks. SATA errors occurred with a WD Red drive in a cheap enclosure; resolved by connecting the same drive directly to the card. | |
| SATA Controller | Ziyituod SATA Card ASM 1062+1093 6-Port | 1b21:0625 | Mainline-4.4 (armbian) | good | tested with 6 disks | |
| SATA Controller | BEYMEI RAID 4-Port, Marvell 88SE9230 chip | 1b4b:9230 | Ayufan-5.6.0-1137 | good | Tested with 3 disks in RAID 5. I added pci=nomsi to /boot/extlinux/extlinux.conf kernel parameters and an udev rule before the disks were recognized: ACTION=="add", SUBSYSTEM=="pci", ATTR{vendor}=="0x1b4b", ATTR{device}=="0x9230", RUN+="/bin/bash -c 'echo %k > /sys/bus/pci/drivers/ahci/bind'" | |
| SATA Controller | BEYIMEI SATA Card 6-Port, ASM1166 chip | 5.10.0-16-arm64 (Debian) | good | Tested with 4 disks. Built 2 separate software RAID-1 arrays without errors. Performance seems good enough for a NAS on gigabit LAN. | ||
| SATA Controller | BEYIMEI SATA Card 2-Port, ASM1062 chip | 1b21:0612 | 5.10.0-19-arm64 (Debian) | good | Using with 2 SSDs in a software RAID-1 array (~190MB/sec for reading and writing) | |
| SATA Controller | QNINE 4-Port, Marvell 88SE9215 chip | Ayufan-5.6.0-1137 | very slow | Tested with 3 disks in RAID 5. Top speeds were around 50 MiB/s but quickly dropped to below 2 MiB/s due to SATA CRC errors | ||
| SATA Controller | DELOCK 90498, JMicron Technology Corp. JMB58x AHCI SATA controller | 197b:0585 | 5.18.0-0.bpo.1-arm64 (Debian bullseye + backports) | good | Tested with 3 disks, two in RAID1, one standalone, no issues | |
| Host Bus Adapter | LSI SAS 9211-4i | 1000:0070 | Ayufan-4.4.197 | good | tested with four disks attached | |
| USB Controller | ASMedia Technology Inc. ASM1142 USB 3.1 Host Controller | 1b21:1242 | Mainline-5.15.0-rc5 | good | ||
| DTMB Quad Tuner | TBS Technologies | TSS6514 | Mainline-5.10.21 | good | TV -> LAN streaming server, 7W idle, 8-10W with one FHD channel streaming | |
| DVB-T2/C Quad Tuner | TBS Technologies | TBS6205 | 5.10.0-16-arm64 (Debian) | good | Working well with Tvheadend |
NVMe SSD drives
| Type | Make/Model | Size | Hardware IDs | Kernel | Result | Notes | Power options Active only |
Save power setting? |
|---|---|---|---|---|---|---|---|---|
| NVMe | Samsung 970 Evo | 500 GB | Mainline 5.6 | good | - | defaults | defaults | |
| NVMe | Samsung 960 Evo | 500 GB | 144d:a804 | Mainline 5.13-rc4 | doesn't work | Likely due to 64/32 BAR mismatch issue on Linux 5.11+ | defaults | defaults |
USB hardware
| Type | Make/Model | Hardware IDs | Kernel | Result | Notes |
|---|
USB C alternate mode DP
Note that only USB C alternate mode Display Port will pass video. Any HDMI, DVI or VGA port must be converted internally by the device from Display Port - or the device won't work for video.
| Type | Make/Model | Hardware IDs | Kernel | Result | Notes |
|---|
Other hardware
| Type | Make/Model | Hardware IDs | Kernel | Result | Notes |
|---|
Limitations
Older firmware overwrites actively used memory
Some people get system freeze when:
- use SATA disk with ROCKPro64 PCIe card. (maybe on newer PCIe card ASM1062 vs ASM1061)
- or do read or write 4GB to the flash. (not using PCIe)
If you connect the serial console you will see a Linux kernel oops: (a)synchronous external abort.
Both issues are in fact the same software BUG. There is no hardware problem. Currently, most OS do use uboot with a rockpro blob FW which use memory that Linux kernel is not aware of.
People are currently fixing this BUG, but it may take some time. In the mean time, you can fix it manually.
The latest u-boot can boot the rockpro64 without any blobs from rockchip.
Install first arm-none-eabi-gcc and aarch64-linux-gnu-gcc compiler, then run the following commands:
Prerequisite packages (Debian/Ubuntu): device-tree-compiler python gcc-arm-non-eabi flex bison gcc-aarch64-linux-gnu gcc make
git clone https://github.com/ARM-software/arm-trusted-firmware.git atf make -C atf CROSS_COMPILE=aarch64-linux-gnu- PLAT=rk3399 bl31 git clone https://gitlab.denx.de/u-boot/u-boot.git u-boot cd u-boot/ git checkout v2020.01-rc5 make rockpro64-rk3399_defconfig BL31=../atf/build/rk3399/release/bl31/bl31.elf make ARCH=arm CROSS_COMPILE=aarch64-linux-gnu-
Which gives you idbloader.img and u-boot.itb. Copy them to the rockpro64, and run the following: (Or put your SD card into your PC)
sudo dd if=idbloader.img of=/dev/mmcblk0 seek=64 sudo dd if=u-boot.itb of=/dev/mmcblk0 seek=16384 sync
PCIe Controller Hardware Error Handling Bug
There is an issue with the rk3399 pcie controller that is currently unmitigated:
The rk3399 pcie controller throws either a synchronous abort or a SError when a pcie device sends an unknown message.
The error type is determined by which cpu cluster handles the message.
Virtualization
The PCIe controller on the rk3399 is not behind an IOMMU. This means it is not possible to safely pass through PCIe devices to a virtual machine.