cdn-dp fec00000.dp: Direct firmware load for rockchip/dptx.bin failed with error -2

[kuerious]

I began this thread (mistakenly?) on the release GitHub page for ayufan-rock64, found here:

https://github.com/ayufan-rock64/linux-build/issues/270

After a few days of no answer there, I figured I should post what's been going on over here in the forums.

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):

Code:

cdn-dp fec00000.dp: Direct firmware load for rockchip/dptx.bin failed with error -2

and

Code:

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]

Initial message(s).

---

Okay, more successful progress. I found this article:

Code:

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:

Code:

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:

Code:

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

---

Ugh. No joy. Does exactly what 0.7.9 does.

Hm. I find this interesting. On this page:

Code:

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.

[dukla2000]

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

Code:

cdn-dp fec00000.dp: Direct firmware load for rockchip/dptx.bin failed with error -2

Those "error" messages are "normal" at the moment - they certainly are not preventing anything working on my setup. Indeed I have no idea what they relate to.

Code:

$ dmesg | grep cdn
[    1.673980] cdn-dp fec00000.dp: Direct firmware load for rockchip/dptx.bin failed with error -2
[    2.675993] cdn-dp fec00000.dp: Direct firmware load for rockchip/dptx.bin failed with error -2
[    4.696233] cdn-dp fec00000.dp: Direct firmware load for rockchip/dptx.bin failed with error -2
[    8.719568] cdn-dp fec00000.dp: [drm:cdn_dp_pd_event_work] Not connected. Disabling cdn

... 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.

Leave it plugged in and use the power button on the board?

PS - while trying to debug and get some confidence in the board would recommend you start with bionic minimal and go from there. Also use the ROCKPro64 wiki page as an index - for sure working from the Rock64 page will be confusing. http://wiki.pine64.org/index.php/ROCKPro...re_Release

[Nesmrten]

I also bought rock64pro and i tried at least 3-4 images of debian and i get:

[ 1.673980] cdn-dp fec00000.dp: Direct firmware load for rockchip/dptx.bin failed with error -2
[ 2.675993] cdn-dp fec00000.dp: Direct firmware load for rockchip/dptx.bin failed with error -2
[ 4.696233] cdn-dp fec00000.dp: Direct firmware load for rockchip/dptx.bin failed with error -2

[cogito808]

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

Code:

cdn-dp fec00000.dp: Direct firmware load for rockchip/dptx.bin failed with error -2

Those "error" messages are "normal" at the moment - they certainly are not preventing anything working on my setup. Indeed I have no idea what they relate to.

I too have the same error message on the OMV console.  I don't think it is effecting anything but I do have a streaming issue to LibreElec causing freezes. I don't think they are related but I cant rule it out at this point yet.

[kuerious]

Hmm.

Well, it seems that it's an errant error message. I will say that, from off to the end of initial boot-up, it sure takes its time. But once its up, it's speedy. This is what I was hoping for buying this particular equipment.

Still have yet to initialize my HDDs. It's a shame I can't use a full 2280 eMMC alongside them ... it'd sure make caching better. But that's what a 6-core/4GB AIO board is for, amirite?

[Bullet64]

Those "error" messages are "normal" at the moment - they certainly are not preventing anything working on my setup. Indeed I have no idea what they relate to.

On my rp64 with pcie-nvme card i have these messages.

Code:

rock64@rockpro64v2_0:~$ dmesg | grep -E "cdn-dp"
[    1.755980] cdn-dp fec00000.dp: Direct firmware load for rockchip/dptx.bin failed with error -2
[    2.757493] cdn-dp fec00000.dp: Direct firmware load for rockchip/dptx.bin failed with error -2
[    4.758402] cdn-dp fec00000.dp: Direct firmware load for rockchip/dptx.bin failed with error -2
[    8.772504] cdn-dp fec00000.dp: [drm:cdn_dp_pd_event_work] Not connected. Disabling cdn

My sys is running fine. No errors with my Samsung 960 EVO.

So i think too, ignore this messages atm. Someone will fix it later...

[t4_4t]

Search for "rockchip/dptx.bin", the following page is found.

"Rockchip Type-C DisplayPort driver"
https://lwn.net/Articles/700405/

According to this,
"rockchip/dptx.bin" seems to be a firmware for "Type-C DisplayPort controller driver".

The people posting here,
Is it using "Type-C DisplayPort" instead of "HDMI-Port" for monitor connection?

[kuerious]

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 traced 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. They're as flawed as I am, I admit.)

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

This series patch is for rockchip Type-C DisplayPort controller driver.

The USB Type-C PHY is designed to support the USB3 and DP applications.
The PHY basically has two main components: USB3 and DisplayPort. USB3
operates in SuperSpeed mode and the DP can operate at RBR, HBR and HBR2
data rates. The Type-C cable orientation detection and Power Delivery
(PD) is accomplished using a PD PHY or an external PD chip.

The DP controller is compliant with DisplayPort Specification,
Version 1.3, This IP is compatible with the rockchip type-c PHY IP.
There is a uCPU in DP controller, it need a firmware to work, please
put the firmware file[0] rockchip/dptx.bin to
/lib/firmware/rockchip/dptx.bin. The uCPU in charge of aux communication
and link training, the host use mailbox to communicate with the ucpu.

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. But basic instructions are as below.

1. Using a simple wget, from root's home directory:

Code:

root@rockpro64:/home/rock64# 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 (works in both Ubuntu and Debian):

Code:

cp /home/rock64/dptx.bin /lib/firmware/rockchip/dptx.bin

Now, on reboot, the error messages go away. I'm so surprised that it worked, I swear I did something wrong.

Critiquing is welcome. Thanks for reading.

(Yes, I run as root. My network's secure, and nobody in my network cares. The closest they get to Linus is saying he walks around with a blanket.)

[Belakor]

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

While this is some good detective work I personally wouldn't be using a random binary blob from the net.  I especially love that the "commit" was the blob itself.

Sure supposedly it's firmware so a binary blob is likely all we would get regardless but why is not available with appropriate checksums from Rockchip?