issues loading firmware and missing pci card

[rich0]

I just got my rockpro64 2gb (board rev 2.1), and while it boots up fine, it isn't detecting my LSI HBA PCIe card.

lspci just gives no output at all, so I don't think it is simply a missing kernel module.

I'm using the debian stretch image off of the wiki.

I'm also getting errors in dmesg that may or may not be relevant:
[    8.566853] cdn-dp fec00000.dp: Direct firmware load for rockchip/dptx.bin failed with error -2
[   16.581959] cdn-dp fec00000.dp: Direct firmware load for rockchip/dptx.bin failed with error -2
[   32.584126] cdn-dp fec00000.dp: Direct firmware load for rockchip/dptx.bin failed with error -2
[   64.586143] cdn-dp fec00000.dp: Direct firmware load for rockchip/dptx.bin failed with error -2
[  128.588049] cdn-dp fec00000.dp: [drm:cdn_dp_request_firmware] *ERROR* Timed out trying to load firmware

I did do an apt-get update/upgrade and rebooted, and the issue persists.  uname -a output:
Linux chunk1 4.4.132-1075-rockchip-ayufan-ga83beded8524 #1 SMP Thu Jul 26 08:22:22 UTC 2018 aarch64 GNU/Linux

That kernel doesn't look terribly fresh...

I'll also go ahead and confess that while I'm quite comfortable with linux inside and out, I rarely use debian-based distros, so please do list complete instructions (typically I use Gentoo) or provide links if you want me to do something like run a custom kernel.  

Any suggestions?

[rich0]

An update: I got the firmware issues resolved (the blob was missing and I just copied it from another distro - the debian image has a pretty old linux-firmware).

However, that did not resolve the PCIe issues. I tried the bionic image and still no luck.

dmesg | grep pci gives me:
[ 0.504108] of_get_named_gpiod_flags: parsed 'gpio' property of node '/vcc3v3-pcie-regulator[0]' - status (0)
[ 0.504158] reg-fixed-voltage vcc3v3-pcie-regulator: Looking up vin-supply from device tree
[ 0.504197] vcc3v3_pcie: supplied by dc_12v
[ 0.504264] vcc3v3_pcie: 3300 mV
[ 0.504419] reg-fixed-voltage vcc3v3-pcie-regulator: vcc3v3_pcie supplying 3300000uV
[ 1.164733] ehci-pci: EHCI PCI platform driver
[ 2.208360] vcc3v3_pcie: disabling
[ 2.740182] phy phy-pcie-phy.9: Looking up phy-supply from device tree
[ 2.740190] phy phy-pcie-phy.9: Looking up phy-supply property in node /pcie-phy failed
[ 2.767504] rockchip-pcie f8000000.pcie: GPIO lookup for consumer ep
[ 2.767514] rockchip-pcie f8000000.pcie: using device tree for GPIO lookup
[ 2.767543] of_get_named_gpiod_flags: parsed 'ep-gpios' property of node '/pcie@f8000000[0]' - status (0)
[ 2.767812] rockchip-pcie f8000000.pcie: Looking up vpcie3v3-supply from device tree
[ 2.767904] rockchip-pcie f8000000.pcie: Looking up vpcie1v8-supply from device tree
[ 2.767913] rockchip-pcie f8000000.pcie: Looking up vpcie1v8-supply property in node /pcie@f8000000 failed
[ 2.767940] rockchip-pcie f8000000.pcie: no vpcie1v8 regulator found
[ 2.771942] rockchip-pcie f8000000.pcie: Looking up vpcie0v9-supply from device tree
[ 2.771962] rockchip-pcie f8000000.pcie: Looking up vpcie0v9-supply property in node /pcie@f8000000 failed
[ 2.771991] rockchip-pcie f8000000.pcie: no vpcie0v9 regulator found
[ 2.775643] rockchip-pcie f8000000.pcie: invalid power supply
[ 3.278857] rockchip-pcie f8000000.pcie: PCIe link training gen1 timeout!
[ 3.285359] rockchip-pcie: probe of f8000000.pcie failed with error -110

[dukla2000]

Sadly the list of successes in the RockPro64 PCIe slot is extremely short (excluding NVMe adapters and the Pine64 SATA card) - check the other threads around here.

Much of what you have in your log is "normal" with current kernel/DT, including the "invalid power supply". My log is below - I have a non-Pine64 NVMe adapter working just fine.

Code:

$ uname -a
Linux rpro64.dukla.net 4.4.138-1100-rockchip-ayufan-g95cecee47f40 #1 SMP Sat Sep 29 15:43:04 UTC 2018 aarch64 aarch64 aarch64 GNU/Linux
chris@rpro64:~$ dmesg | grep pcie
[    0.505910] of_get_named_gpiod_flags: parsed 'gpio' property of node '/vcc3v3-pcie-regulator[0]' - status (0)
[    0.505958] reg-fixed-voltage vcc3v3-pcie-regulator: Looking up vin-supply from device tree
[    0.505998] vcc3v3_pcie: supplied by dc_12v
[    0.506064] vcc3v3_pcie: 3300 mV
[    0.506223] reg-fixed-voltage vcc3v3-pcie-regulator: vcc3v3_pcie supplying 3300000uV
[    2.896829] vcc3v3_pcie: disabling
[    3.189423] phy phy-pcie-phy.9: Looking up phy-supply from device tree
[    3.189432] phy phy-pcie-phy.9: Looking up phy-supply property in node /pcie-phy failed
[    3.192960] rockchip-pcie f8000000.pcie: GPIO lookup for consumer ep
[    3.192990] rockchip-pcie f8000000.pcie: using device tree for GPIO lookup
[    3.193080] of_get_named_gpiod_flags: parsed 'ep-gpios' property of node '/pcie@f8000000[0]' - status (0)
[    3.193776] rockchip-pcie f8000000.pcie: Looking up vpcie3v3-supply from device tree
[    3.194052] rockchip-pcie f8000000.pcie: Looking up vpcie1v8-supply from device tree
[    3.194082] rockchip-pcie f8000000.pcie: Looking up vpcie1v8-supply property in node /pcie@f8000000 failed
[    3.194149] rockchip-pcie f8000000.pcie: no vpcie1v8 regulator found
[    3.212873] rockchip-pcie f8000000.pcie: Looking up vpcie0v9-supply from device tree
[    3.212919] rockchip-pcie f8000000.pcie: Looking up vpcie0v9-supply property in node /pcie@f8000000 failed
[    3.212996] rockchip-pcie f8000000.pcie: no vpcie0v9 regulator found
[    3.249922] rockchip-pcie f8000000.pcie: invalid power supply
[    3.322404] PCI host bridge /pcie@f8000000 ranges:
[    3.351488] rockchip-pcie f8000000.pcie: PCI host bridge to bus 0000:00
[    3.430779] pcieport 0000:00:00.0: enabling device (0000 -> 0002)
[    3.438222] pcieport 0000:00:00.0: Signaling PME through PCIe PME interrupt
[    3.452071] pcie_pme 0000:00:00.0:pcie01: service driver pcie_pme loaded
[    3.452389] aer 0000:00:00.0:pcie02: service driver aer loaded

{I stick to 4.4.138-1100 if I want sound, I use 4.19 to overclock.}

[MisterA]

Could you explain how you update the kernel to the latest one?
If I install 4.18 for example my rockpro64 fails to boot.

[jja2000]

https://forum.pine64.org/showthread.php?tid=6685

I have exactly the same problem, also with the SATA card pine64 sells in the shop here.

No real way to check what the problem is sadly since we got no communication from devs or pine64 themselves.

[dukla2000]

Could you explain how you update the kernel to the latest one?
If I install 4.18 for example my rockpro64 fails to boot.

OK, it all depends on /boot/extlinux/extlinux.conf and also what is in your /boot directory. After a basic install of say the 0.7.9 (stable) Ayufan minimal release you will only have 1 kernel in your filesystem - in /boot/ you will have 1 of each config..., initrd... and vmlinux...

Now, I find it easier to find kernels using synaptic (a gui). And 4.18 has no merit any longer as 4.19 has hit the streets. You can of course do this all from a Linux command line, and there are other gui tools.

So doing it my way, start synaptic, and hit the big Reload button (which effectively is an apt-get update)
Then hit Search, and look for linux-image-4.19
There are about 12 results today, and mostly in pairs. If you expand the Package column you will see each result has a -dbg mate which is a complete debug version. I ignore them - I am sure they have a use but so far my life has been just fine without a debug kernel!
Many of the results are 4.19.0-rc4... , these are versions Ayufan cooked from release candidate 4 which is now pretty much deceased.
The only 1 of real interest is 4.19.0-1073... - select it (but not the -dbg one)
Click the Mark all Upgrades button (if you haven't upgraded your Linux recently)
Then click the Apply button

When synaptic has finished playing, exit and check /boot/extlinux/extlinux.conf and also what is in your /boot directory again. You should now have 4.19 scattered about in addition to what you had before. The key to deciding which kernel when booting is the .conf, and you can set a default from the options there. My file is currently

Code:

$ cat /boot/extlinux/extlinux.conf
timeout 10
menu title select kernel
default kernel-4.4.138-1100-rockchip-ayufan-g95cecee47f40

label kernel-4.19.0-1073-ayufan-ga6e013135a6e
    kernel /boot/vmlinuz-4.19.0-1073-ayufan-ga6e013135a6e
    initrd /boot/initrd.img-4.19.0-1073-ayufan-ga6e013135a6e
    devicetreedir /boot/dtbs/4.19.0-1073-ayufan-ga6e013135a6e
    append rw panic=10 init=/sbin/init coherent_pool=1M ethaddr=${ethaddr} eth1addr=${eth1addr} serial=${serial#} cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory swapaccount=1 root=LABEL=MySM961 rootwait rootfstype=ext4

label kernel-4.19.0
    kernel /boot/vmlinuz-4.19.0
    initrd /boot/initrd.img-4.19.0
    devicetreedir /boot/dtbs/4.19.0
    append rw panic=10 init=/sbin/init coherent_pool=1M ethaddr=${ethaddr} eth1addr=${eth1addr} serial=${serial#} cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory swapaccount=1 root=LABEL=MySM961 rootwait rootfstype=ext4

label kernel-4.4.138-1100-rockchip-ayufan-g95cecee47f40
    kernel /boot/vmlinuz-4.4.138-1100-rockchip-ayufan-g95cecee47f40
    initrd /boot/initrd.img-4.4.138-1100-rockchip-ayufan-g95cecee47f40
    devicetreedir /boot/dtbs/4.4.138-1100-rockchip-ayufan-g95cecee47f40
    append rw panic=10 init=/sbin/init coherent_pool=1M ethaddr=${ethaddr} eth1addr=${eth1addr} serial=${serial#} cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory swapaccount=1 root=LABEL=MySM961 rootwait rootfstype=ext4

Note the 3rd line I have added, which currently selects the 4.4 option at the bottom. Without that default entry the first option will be used. Also note this is your "Get out of jail free" card: if you screw up and have a duff kernel that wont do what you want, you can just change the default and try again. At worst you may need to mount your SDcard or eMMC (whichever you use to boot) in another Linux box and edit it there.

Hope this helps

[rich0]

I've tried linux 4.19.0 and I'm still not having any luck getting the PCIe slot to work.

Does anybody have any suggestions? Is there any way to engage the vendor for support? I bought the card for the PCIe slot, so if it doesn't actually work the card is probably going to end up being useless, which means I'll probably be seeking a full refund from them. However, I don't mind putting some effort into getting it working if there is someplace reasonable to start...

[rich0]

FYI, a kernel is now available with a fix for the LSI issues:
https://github.com/nuumio/linux-kernel/r...n-sleep-02

The changes look like they should be released as part of ayufan soon, if they aren't already in there.

These do require a command line parameter pcie_rk_bus_scan_delay=1500 to work (consider experimenting with the delay).

I was also having power issues due to using the pine64 3A power supply.  A 5A power supply is probably more likely to work with an LSI HBA due to the card drawing 2A on its own.

ayufan has been merging a bunch of other pcie patches as well, so anybody with other issues may want to test the latest release.