Error on console on first boot: "cdn-dp fec00000.dp: Direct firmware load for rockchip/dptx.bin failed with error -2"

[kuerious]

Hello all. Big, big fan of your hard work and determination, ayufan.

The following occurred using both of these images:
1: stretch-openmediavault-rockpro64-0.7.9-1067-arm64.img.xz
2: stretch-openmediavault-rockpro64-0.7.9-1067-armhf.img.xz

The title says it all. On first boot, the console shows the following error more than once (at least twice):

cdn-dp fec00000.dp: Direct firmware load for rockchip/dptx.bin failed with error -2
and
cdn-dp fec00000.dp: [drm:cdn_dp_request_firmware] *ERROR* Timed out trying to load firmware

The first few times I attempted to get to the IP, the screen loaded blue but nothing else. After it timed-out, I tried a Ctrl+F5 (clean refresh), and it loaded even less this time. I did the usual troubleshooting: let it run for awhile, then reboot - no change; tried the other image for OMV on Rock64Pro - no change.

So I decided to give it some time, see if I could think of anything I missed. I unplugged the power (why, oh why, did the Pine64 team NOT include a power button on the power supply? There's no chance to press the small board button after you plug it in - it just boots.)

I just came back, again, plugged it in. Nothing different. Nothing at all. The SAME error messages occur, but this time the web interface works. It even times me out (as it should) when I'm not active. So, that's weird. But is it functional?

My issue is, if the unit says the firmware isn't loading, should I try using it? As well, did I choose the incorrect images? Did I miss a step?

1: Built the unit (Pine64 storage case + Rock64Pro + 2x 6TB drives + 12V/6A power supply)
2: Used Etcher to load images (above) to 16GB Class 10 microSD
3: Booted

Please tell me what to try next ...

[kuerious]

[kuerious]

Okay, more successful progress. I found this article:

https://forum.pine64.org/showthread.php?tid=6259&pid=39084

That one seemed to be fixed by changing versions (in their case, 0.7.3 -> 0.6.59). So I went looking for the "official" build. Found this on the wiki page:

http://wiki.pine64.org/index.php/ROCK64_Software_Release#Stretch_OpenMediaVault_OS_Image_arm64_.5BmicroSD_.2F_eMMC_Boot.5D_.5B0.7.8.5D

Clicking the download link revealed (either because it's an old link, or because it's the version that is known to work) that it downloaded version 0.7.8 instead of the 0.7.9 I had already.

I will work on this and update as I discover more.

Edit

Looks like that link gave me the "Rock64", not the "Rock64Pro" (which is my hardware). Had to manually enter to get to the correct version:

https://github.com/ayufan-rock64/linux-build/releases/tag/0.7.8

[kuerious]

Ugh. No joy. Does exactly what 0.7.9 does.

Time for more research ... just not tonight.

[kuerious]

Hm. I find this interesting. On this page:

http://wiki.pine64.org/index.php/ROCK64_Software_Release#OpenMediaVault

users are provided both of the Stretch versions ("armhf" and "arm64" for 0.7.8), and a (previous, I'm guessing?) third Jessie version, named/version "0.5.15-136". I haven't tried the Jessie version, nor the "arm64" of version 0.7.8.

I think I'll also try unplugging the PCIe card (using the Pine64-provided PCIe-to-SATA adapter), since a few sections in the forums suggested it in various troubleshooting attempts.

[cogito808]

Same issue. I found this suggestion:
Hi mikeD, I just found out that is a problem of usb3.0 driver, you should copy dptx.bin into rootfs folder /lib/firmware/rockchip/dptx.bin (https://forum.pine64.org/showthread.php?tid=6085&pid=38290)
But there was no folder called rockchip.

[kuerious]

I started a thread on the Pine64 forums, found here, and after troubleshooting further I hacked together a fix for the issue, found at post #9. I'll put relevant information below.

I think I found** the permanent fix for this particular error message.

After digging around a LOT of forums in regards to the filename (dptx.bin), I found not only the original commit in 2016 for this file in a chromiumOS forum (see this post) and where it belongs (see this post), but I also tracked it down to what the file's purpose is (listed below). I was also able to find the actual dptx.bin file necessary to make the problem go away. This was done in both Debian and Ubuntu images from Ayufan.

(**I don't assume I'm the 1st one to find this, but I didn't find the answer in my searches.)

Original Commit, from Chromium OS checkins, dated 7/21/16
https://i.imgur.com/fGAD5RB.png

After scouring (and trial-and-error), I found the appropriate file in the following repo location:
https://github.com/wkennington/linux-fir...p/dptx.bin

I'm even going to attach it, in case the repo goes bye-bye. [Note: attaching file here, as well.]

Note: for those whom don't like doing things as root, insert sudo instructions as necessary.

1. Using a simple wget, from root's home directory:
   wget https://raw.githubusercontent.com/wkennington/linux-firmware/master/rockchip/dptx.bin

2. Now, copy it over to the requisite directory where it's expected to be (adjust for Ubuntu vs Debian):
   mkdir /lib/firmware/rockchip cp /home/root/dptx.bin /lib/firmware/rockchip/dptx.bin

Now, on reboot, the error messages go away.

Firmware file:
dptx.bin.gz