usual user Posted December 15, 2020 Posted December 15, 2020 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 Posted December 15, 2020 Posted December 15, 2020 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 Posted December 16, 2020 Author Posted December 16, 2020 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 Posted December 17, 2020 Posted December 17, 2020 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 Posted December 17, 2020 Author Posted December 17, 2020 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 Posted December 17, 2020 Posted December 17, 2020 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 Posted December 17, 2020 Author Posted December 17, 2020 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 Posted December 18, 2020 Author Posted December 18, 2020 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 Posted December 18, 2020 Posted December 18, 2020 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 Posted December 18, 2020 Author Posted December 18, 2020 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 Posted December 22, 2020 Posted December 22, 2020 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 Posted December 23, 2020 Author Posted December 23, 2020 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 Posted December 24, 2020 Posted December 24, 2020 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 Posted December 26, 2020 Posted December 26, 2020 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 Posted December 26, 2020 Author Posted December 26, 2020 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 Posted January 4, 2021 Posted January 4, 2021 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 Posted January 4, 2021 Author Posted January 4, 2021 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 Posted January 6, 2021 Posted January 6, 2021 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 Posted January 7, 2021 Author Posted January 7, 2021 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 Posted January 9, 2021 Posted January 9, 2021 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 Posted January 9, 2021 Author Posted January 9, 2021 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 Posted January 10, 2021 Posted January 10, 2021 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 Posted January 11, 2021 Author Posted January 11, 2021 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 Posted January 11, 2021 Posted January 11, 2021 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 Posted February 27, 2021 Posted February 27, 2021 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 Posted April 29, 2021 Posted April 29, 2021 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 Posted April 30, 2021 Posted April 30, 2021 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
Recommended Posts