USB Type-C DisplayPort Alternate Mode Support for NanoPC-T4

[usual user]

On 12/13/2020 at 6:31 PM, RussianNeuroMancer said:

Pull request mention HDMI specifically:https://github.com/armbian/build/pull/2302 

Thank you for sharing the link. Inspired me to write an overlay for my NanoPC-T4.
Now I can attach an additional monitor via my Delock 63959 USB-C to VGA / HDMI / DVI / DisplayPort Adapter with 5.10.0.

[RussianNeuroMancer]

1 hour ago, usual user said:

Thank you for sharing the link. Inspired me to write an overlay for my NanoPC-T4.

Could you please share your solution here:

 

[usual user]

13 hours ago, RussianNeuroMancer said:

Could you please share your solution here:

This discussion is off-topic here, a moderator should move it to a proper thread starting with my previous post in this thread.

I do not use code referenced here. I also do not use Armbian user space, but IMHO my overlay should also work there.
To verify this a test has to be done:

- Use a mainline kernel with this patch applied

- Backup the original dtb, e.g.:

mv rk3399-nanopc-t4.dtb rk3399-nanopc-t4.dtb.orig

- Apply rk3399-nanopc-t4-tc.dtbo, e.g.:

fdtoverlay -i rk3399-nanopc-t4.dtb.orig -o rk3399-nanopc-t4.dtb rk3399-nanopc-t4-tc.dtbo

- Reboot and test if Type-C DP is working

If confirmed I will also provide the overlay source for Armbian integration.

rk3399-nanopc-t4-tc.dtbo

[RussianNeuroMancer]

On 12/16/2020 at 6:16 PM, usual user said:

To verify this a test has to be done

Tested this on both of 5.9 and 5.10 - typec works with this overlay, but displayport over typec - doesn't.

[usual user]

1 hour ago, RussianNeuroMancer said:

displayport over typec - doesn't

The only observation I made during the test was that I must have connected the monitor to the adapter and turned it on before connecting the Type-C connector. Otherwise the display won't be working.

[RussianNeuroMancer]

6 hours ago, usual user said:

The only observation I made during the test was that I must have connected the monitor to the adapter and turned it on before connecting the Type-C connector. Otherwise the display won't be working.

Yep, this is what I did. Except, in my case I attaching not adapter but docking station that works as USB hub as well (Belkin F4U093). I wonder if mixed mode (when connector is used for both of USB and DP) is excepted to work at this stage?

[usual user]

3 hours ago, RussianNeuroMancer said:

I wonder if mixed mode (when connector is used for both of USB and DP) is excepted to work at this stage?

I don't know what the kernel patch code is capable of. Was just through your link aware of its existence  I only extended my DT-overlay with the support for the patch. Maybe I'm just lucky it fits my needs. The extcon-cables property may determine to some extent the capabilities, but I see no binding documentation. Since the patch is used by Pinebook Pro and Helios64, there may be some reports about its capabilities to be found there.

[usual user]

On 12/17/2020 at 12:04 PM, RussianNeuroMancer said:

displayport over typec - doesn't

What's in my mind right now, you have dptx.bin firmware in place since it is required for USB DisplayPort?

[RussianNeuroMancer]

24 minutes ago, usual user said:

What's in my mind right now, you have dptx.bin firmware in place since it is required for USB DisplayPort?

Yes, it's installed as part of linux-firmware package.

[usual user]

28 minutes ago, RussianNeuroMancer said:

Yes, it's installed as part of linux-firmware package.

And USB Type-C kernel components are build as modules? If build-in, the firmware must also be build-in, otherwise it cannot be loaded.

[RussianNeuroMancer]

On 12/19/2020 at 3:11 AM, usual user said:

And USB Type-C kernel components are build as modules? If build-in, the firmware must also be build-in, otherwise it cannot be loaded.

I don't know what components I should check. Anyway, it's seems like Armbian use same .config for boards where DisplayPort works (Helios64 and PineBook Pro) and boards where it doesn't work (like mine, at least at this moment). Just in case, I didn't changed Armbian default config, so I using .config that you can find below:

 

https://github.com/armbian/build/blob/master/config/kernel/linux-rockchip64-current.config

https://github.com/armbian/build/blob/master/config/kernel/linux-rockchip64-dev.config

[usual user]

23 hours ago, RussianNeuroMancer said:

I don't know what components I should check.

Unfortunately my config and the armbian config diverge quite a lot and it is not easy to identify the relevant differences. The only help I could offer further is to run your environment with my kernel to identify whether the kernel is the culprit or something else.
If you want to try this, you have to post the output of the following commands:

cat /proc/cmdline
ls -hal /boot
lsblk -o +PARTUUID

so I can prepare the experiment.

[RussianNeuroMancer]

13 hours ago, usual user said:

If you want to try this, you have to post the output of the following commands

 

Sure, we could try this, but for further test I will use one of spare NanoPC-T4 I have on hands (above I tested board running in production) with fresh image from downloads. It will probably take a few days until I find time to deploy the image to sd card and post output (hopefully I will manage to do so in Saturday) so in case you find free time earlier than I do - you probably could retrieve all needed information from Armbian image itself.

 

Or, alternatively, I could try to build 5.10 with your config.

[RussianNeuroMancer]

On 12/24/2020 at 1:13 AM, usual user said:

If you want to try this, you have to post the output of the following commands

 

~# cat /proc/cmdline
root=UUID=1381bbaa-1ce4-41e6-8e85-2ae1d4a974e2 rootwait rootfstype=ext4 console=ttyS2,1500000 console=tty1 consoleblank=0 loglevel=1 ubootpart=7ac8d505-01 usb-storage.quirks=0x2537:0x1066:u,0x2537:0x1068:u   cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory swapaccount=1

~# ls -hal /boot
итого 65M
drwxr-xr-x  3 root root 4,0K дек 27 03:57 .
drwxr-xr-x 19 root root 4,0K дек 12 17:46 ..
-rw-r--r--  1 root root  166 дек 27 03:57 armbianEnv.txt
-rw-r--r--  1 root root 1,5K дек 12 17:50 armbian_first_run.txt.template
-rw-r--r--  1 root root  38K дек 12 17:50 boot.bmp
-rw-r--r--  1 root root 3,1K дек 12 17:46 boot.cmd
-rw-rw-r--  1 root root 3,2K дек 12 17:51 boot.scr
-rw-r--r--  1 root root 212K дек 15 15:52 config-5.9.14-rockchip64
lrwxrwxrwx  1 root root   21 дек 27 02:55 dtb -> dtb-5.9.14-rockchip64
drwxr-xr-x  6 root root 4,0K дек 27 02:54 dtb-5.9.14-rockchip64
lrwxrwxrwx  1 root root   25 дек 27 02:55 Image -> vmlinuz-5.9.14-rockchip64
-rw-r--r--  1 root root  17M дек 27 02:55 initrd.img-5.9.14-rockchip64
-rw-r--r--  1 root root    0 дек 27 02:55 .next
-rw-r--r--  1 root root 5,5M дек 15 15:52 System.map-5.9.14-rockchip64
lrwxrwxrwx  1 root root   25 дек 27 02:55 uInitrd -> uInitrd-5.9.14-rockchip64
-rw-r--r--  1 root root  17M дек 27 02:55 uInitrd-5.9.14-rockchip64
-rw-r--r--  1 root root  27M дек 15 15:52 vmlinuz-5.9.14-rockchip64

~# lsblk -o +PARTUUID
NAME         MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT PARTUUID
mmcblk2      179:0    0 14,6G  0 disk            
mmcblk2boot0 179:32   0    4M  1 disk            
mmcblk2boot1 179:64   0    4M  1 disk            
mmcblk1      179:96   0 29,8G  0 disk            
└─mmcblk1p1  179:97   0 29,5G  0 part /          7ac8d505-01
zram0        252:0    0   50M  0 disk /var/log   
zram1        252:1    0  1,9G  0 disk [SWAP] 

 

[usual user]

OK, here is the preperation for our experiment:

- create an extlinux directory in your root, e.g. mkdir /extlinux
- copy the attached extlinux.conf into it
- reboot and check if the device is now booting with distro-boot method

The auto boot timeout is set to 10 seconds, so be patient.
If this is working I will upload my kernel and you can put it in for the test.

extlinux.conf

[RussianNeuroMancer]

On 12/27/2020 at 7:16 AM, usual user said:

OK, here is the preperation for our experiment:

- create an extlinux directory in your root, e.g. mkdir /extlinux
- copy the attached extlinux.conf into it
- reboot and check if the device is now booting with distro-boot method

The auto boot timeout is set to 10 seconds, so be patient.
If this is working I will upload my kernel and you can put it in for the test.

extlinux.conf 1.16 kB · 10 downloads

 

I see menu but it's seems like it doesn't accept keyboard input, probably due to the fact that my keyboard is attached via USB dock. But since it separate board specifically for testing it's fine, really.

 

During testing I found interesting difference between old Armbian installation running on first NanoPC-T4 that I been used for testing of your rk3399-nanopc-t4-tc.dtbo and fresh Armbian installation I running on second NanoPC-T4 where I tested this extlinux.conf. The difference is incompatibility with Dell UP3017, which I previously mentioned in first paragraphs of this message, is also reproducible on second NanoPC-T4 too. Since I tried to run exactly same kernel on both boards, I think this difference could be caused by much older uboot (probably something from 2019) flashed to eMMC on first NanoPC-T4.

 

By taking into account difference in uboot I re-tested rk3399-nanopc-t4-tc.dtbo on second NanoPC-T4 but DisplayPort still doesn't work. By the way, there is "typec_displayport port0-partner.0: No compatible pin configuration found:0000 -> 000c, 001c <- 0000" error message in dmesg. Does it tell something useful?

 

I will try to build image with uboot v2020.10 just to see if it will help with HDMI or DisplayPort.

 

[usual user]

4 hours ago, RussianNeuroMancer said:

I see menu but it's seems like it doesn't accept keyboard input, probably due to the fact that my keyboard is attached via USB dock.

IIUC the extlinux.conf is working with the current kernel for you. The USB keyboard is not expected to work, because mainline uboot does not yet have the necessary support enabled. Boot option selection is only available via serial console for now.

Extract the tar-gz kernel archive, which can be found here, in your /usr/lib/modules/ directory. E.g.:

tar -C /usr/lib/modules/ -xzf 5.10.0-98.fc34.aarch64.tgz

and reboot. Extlinux.conf will pick it up by the default option. To fall back to original kernel without boot option selection, rename the symlink /usr/lib/modules/linux-default, e.g.: linux-default-disabled

[RussianNeuroMancer]

On 1/4/2021 at 8:21 PM, usual user said:

The USB keyboard is not expected to work, because mainline uboot does not yet have the necessary support enabled. Boot option selection is only available via serial console for now.

Thanks for explanation!

 

I tested this build and unfortunately DisplayPort still doesn't work (dmesg). HDMI issue I mentioned earlier is also there.

Just in case, on vendor's 4.4 DisplayPort works work with same docking station (at least on ROCKPro64, but I could test it again on NanoPC-T4, if necessary).

[usual user]

Okay, I can only imagine two reasons for this still not working. Either the DP kernel patch doesn't support your DP hardware or u-boot doesn't set up the NanoPC-T4 as needed. To rule out u-boot, apply the extracted u-boot, which can be found here. E.g:

dd bs=512 seek=64 conv=notrunc if=u-boot-rockchip.bin of=${DEVICE} ; sync

and test. Replace "${DEVICE}" by your micro-SD device. 

[RussianNeuroMancer]

On 1/8/2021 at 4:18 AM, usual user said:

Either the DP kernel patch doesn't support your DP hardware or u-boot doesn't set up the NanoPC-T4 as needed.

 

Flashed uboot, displayed version during changed from 2020.07-armbian to 2020.10 with zero timestamp, so I guess it's yours. Unfortunately, still same error: "typec_displayport port0-partner.0: No compatible pin configuration found:0000 -> 000c, 001c <- 0000". But it's seems like I shouldn't be using NanoPC-T4 for testing DP stuff at all. Turns out DP doesn't work for me on this board even with vendor's FriendlyDesktop image based on Rockchip 4.4 branch - getting "cdn-dp fec00000.dp: [drm:cdn_dp_pd_event_work] Not connected. Disabling cdn" error in dmesg. Perhaps there is some incompatibility between this specific boards and this specific dock? (No idea how this would be possible, but not sure what else could be happening here.)

 

Anyway, DisplayPort do work for me on ROCKPro64 (with PINE64 image) and Libre Computer Renegade Elite (with Firefly image). I don't have spare ROCKPro64 on hands right now, but I could use ROC-RK3399-PC for further testing - is there chance you could prepare dtbo file for this board? Actually, vendor said everything should be in upstream by now, but even with uboot 2020.1 and Linux 5.10 DisplayPort doesn't work for me, at least on Armbian. If you have time for this, we could continue here.

[usual user]

IIUC the PINE64 and Firefly image use legacy kernel and don't use this particular kernel patch. Now that the only difference in our setups is the USB DP adapter, IMHO the only sensible way forward is to swap the dock for another DP alternate mode adapter. Swapping the board will not eliminate an incompatibility between the kernel patch and the dock. The USB-C hardware (DTB) seems to be set up correctly otherwise the USB functionality would not work. The DP alternate mode uses the same hardware lanes but only protocolly differently.
Off topic: Out of curiosity does the offered u-boot influence your Dell UP3017 incompatibility?

[RussianNeuroMancer]

18 hours ago, usual user said:

IIUC the PINE64 and Firefly image use legacy kernel and don't use this particular kernel patch.

Yes, sure. I guess all three 4.4 kernels (by Firefly, PINE64 and FriendlyARM) is based on Rockchip code?

 

18 hours ago, usual user said:

IMHO the only sensible way forward is to swap the dock for another DP alternate mode adapter.

I could try to get Dell DA300 for testing (it probably will take a few weeks) but I would not be able to use it in practice for anything but just testing. In practice I'll still need Belkin F4U093, because there is not many docking stations out there that can charge anything PD-compatible. I tried several docks, from Dell WD15 to StarTech TB3CDK2DP, but after all I had to stick with Belkin F4U093, because Dell and Lenovo docks refuse to charge old HP laptops, StarTech refuse to communicate with Qualcomm USB implementation and doesn't charge HP laptops too, HP docks doesn't charge old Dell laptops, and so on, and so on... so unfortunately Belkin dock is solution with most broad compatibility, and I have to choice but to stick with it for now.

 

18 hours ago, usual user said:

Swapping the board will not eliminate an incompatibility between the kernel patch and the dock.

Please clarify why you think this incompatibility is caused by patch, while even vendor kernel couldn't use this dock as video output on this specific board? Please take into account that ROCKPro64 (with vendor 4.4 kernel) and Libre Computer Renegade Elite (with vendor 4.4 kernel) works with this dock, while NanoPC-T4 (with vendor 4.4 kernel) does not.

 

18 hours ago, usual user said:

Out of curiosity does the offered u-boot influence your Dell UP3017 incompatibility?

No, HDMI output still doesn't work on both of 2020.07 and 2020.10. I had yet to bisect how it was broken and when.

[usual user]

20 hours ago, RussianNeuroMancer said:

Belkin dock is solution with most broad compatibility, and I have to choice but to stick with it for now.

You probably have a misunderstanding about what this thread is about. It is about to verify if my DT overlay is working in Armbian environment so it can be integrated in Armbian for out of the box operation of Armbian users. It is sufficient to aprove it is working in a similar manner as for me. If a special USB-C device does not work, this is possible to discuss with the patch autor. PD functionality is for NanoPC-T4 out of scope because it has no PD features desined in hardware. The NanoPC-T4 can e.g. operate an additional display via a cost-effective USB-C DP alternative mode adapter.

 

20 hours ago, RussianNeuroMancer said:

Please clarify why you think this incompatibility is caused by patch, while even vendor kernel couldn't use this dock as video output on this specific board?

Vendor kernels are havy out of tree patched to showcase the key features of a specific hardware. But never implement everything perfect. Otherwise noone would have any demand for any update ever. The fact that the NanoPC-T4 vendor kernel does not have functional USB-C DP support is even understandable, as it already has three dedicated display connectors. Support for a fourth one is therefore likely to be a very low priority and left out. But the hardware is there and can be used with proper software, as proven for my environment. If other vendor kernels support your device they have probably some necessary modification in place and aprove the 3399 SOC can drive it.

Starting here and the following posts you can find success of using USB-C DP with legacy kernel.

[RussianNeuroMancer]

7 minutes ago, usual user said:

You probably have a misunderstanding about what this thread is about. It is about to verify if my DT overlay is working in Armbian environment so it can be integrated in Armbian for out of the box operation of Armbian users. It is sufficient to aprove it is working in a similar manner as for me. If a special USB-C device does not work, this is possible to discuss with the patch autor. PD functionality is for NanoPC-T4 out of scope because it has no PD features desined in hardware. The NanoPC-T4 can e.g. operate an additional display via a cost-effective USB-C DP alternative mode adapter.

Oh, sure, I perfectly understand this, which is why I going to try to get Dell DA300 so we can proceed with this (I am just afraid it will get some time until I will get it on hands). I just explained why it would not help in my particular use-case, that all

 

12 minutes ago, usual user said:

Vendor kernels are havy out of tree patched to showcase the key features of a specific hardware. But never implement everything perfect. Otherwise noone would have any demand for any update ever. The fact that the NanoPC-T4 vendor kernel does not have functional USB-C DP support is even understandable, as it already has three dedicated display connectors. Support for a fourth one is therefore likely to be a very low priority and left out. But the hardware is there and can be used with proper software, as proven for my environment. If other vendor kernels support your device they have probably some necessary modification in place and aprove the 3399 SOC can drive it.

Starting here and the following posts you can find success of using USB-C DP with legacy kernel.

Right, I totally forgot I could try Armbian legacy builds too. Thanks for reminder!

 

Armbian_20.11.7_Nanopct4_bionic_legacy_4.4.213_desktop.img:
Can't setup desktop due to "Cannot execute /usr/bin/bash: No such file or directory" error.
When only Type-C cable is attached - there is no picture on external display.
Same flicker via HDMI during boot, but then kernel probably re-initialize display and I can see text console properly (but can not interact with it without bash; ssh doesn't work too).

Tried older image instead:
Armbian_20.02.7_Nanopct4_bionic_legacy_4.4.213_desktop.img:
No HDMI flicker during boot. DisplayPort still does not work (no errors, not even mentioned in dmesg during connection).
 
I also remember there is convenient way to start with my HDMI issues:
Armbian_20.05.7_Nanopct4_focal_current_5.4.49.img - issue is not reproducible,
Armbian_20.08.2_Nanopct4_focal_current_5.8.6.img - issue is reproducible.
 
So between this and this tags there was this commit. I guess first things I should do regarding HDMI issue is to try flash uboot 2020.04 (building it now) on newer Armbian image and see if it help to get HDMI working.

[RussianNeuroMancer]

Re-tested with Dell DA300 - no positive changes.

https://pastebin.ubuntu.com/p/pDsdRpmHCr/

 

(PARTUUID is different, as it's seems I like accidentally wiped microSD I used for testing DisplayPort last time, so I had to repeat all this extelinux, kernel extract and uboot steps, with adjusting PARTUUID in extlinux.conf.)

[RussianNeuroMancer]

Tested Armbian with Linux 5.10.32 (just downloaded fresh focal gnome image from device page and then boot it from microSD; emmc is clear so uboot from microSD is in use) that should include this commit, as I understand (at least CONFIG_EXTCON_USBC_VIRTUAL_PD is y in /boot/config-5.10.32-rockchip64).

Unfortunately, Type-C video output does not work with adapter (Dell DA300) dock (Belkin F4U093) and even Type-C display (Lenovo L27m-28). I aways end up with

[  261.588312] cdn-dp fec00000.dp: [drm:cdn_dp_pd_event_work [rockchipdrm]] Not connected. Disabling cdn
[  261.610196] typec_displayport port0-partner.0: No compatible pin configuration found:0000 -> 000c, 001c <- 0000

 

And yes, I tried to attach cable upside down with every tested device - error is still the same. (logs)

 

@TonyMac32 any idea why it could fail for me? Hardware is fine - issue it not reproducible with legacy kernel.

 

[  174.603036] fusb302 4-0022: attention, dp_status 9a
[  174.603174] cdn-dp fec00000.dp: [drm:cdn_dp_pd_event_work] Connected, not enabled. Enabling cdn
[  174.893175] rockchip-vop ff8f0000.vop: [drm:vop_crtc_enable] Update mode to 2560x1600p0, type: 10

 

And then picture appear on the screen (attached via Type-C).

[TonyMac32]

I'll have to take a look at it, I also have to implement this on a couple other RK3399 boards so I'll review the T4 first to make sure my example is still working