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.

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

The image was provided to identify a boot.scr magic deficiency. Also Fedora 31 is EOL, so image RIP. Since there seems to be more shortage there, as long as no one who cares for Armbian shows up and maintain the boot.scr magic, you are on your own.

It is a hardware flaw due to a missing pull resistor and a software quirk. A fix is discussed here but as long as noone with an affected device confirms it, probably nothing will happen.

IMHO I think from version 5.10.0 the path won't change again because generic node names have been around since then. Therefore, the same DTBO can always be applied. But as long as the hardware setup doesn't change, there's no reason to ever change the DTB. Therefore, after an update, restoring the DTB from a persistent location would also be an option. But I guess you will have more fun to keep having the boot.scr magic in place. And tinkering with boot.scr magic opens even the option to load the DTB from the persistent location direct or choose a different DTB file name that wouldn't be overwritten.

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

Applies for me flawless. fdtoverlay -V Version: DTC 1.6.0 fdtoverlay -v -i imx6q-hummingboard.dtb.orig -o imx6q-hummingboard.dtb imx6q-hummingboard-gpio.dtbo input = imx6q-hummingboard.dtb.orig output = imx6q-hummingboard.dtb overlay[0] = imx6q-hummingboard-gpio.dtbo The overlay is written for DTS comming with 5.10.0 kernel. Over time, some node names have been renamed to improve homogeneity. Attempting to apply it to an older release may fail.

Maybe somthing like imx6q-hummingboard-gpio.dts. Compile it with DTC and apply it as follows: mv imx6q-hummingboard.dtb imx6q-hummingboard.dtb.orig fdtoverlay -i imx6q-hummingboard.dtb.orig -o imx6q-hummingboard.dtb imx6q-hummingboard-gpio.dtbo But since I don't know your PAD configuration requirements, I only chose one random one. You have to look up your needs yourself. imx6q-hummingboard-gpio.dts

Just switched to 5.10.0. I noticed that the DTB has changed multiple node names. As a result, my user space could no longer apply all configuration quirks due to the changed paths in sysfs. Useing a DTB before 5.7.x resolved all observed regressions for me. Perhaps it is also worth trying in your case to run the current kernel with a pre 5.7.x DTB as a test.

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.

Either fix the boot.scr magic or switch to distro-boot by inserting an extlinux.conf. For background maybe start reading here and here. I usually write DT-overlays for my board extensions and apply them to the base DTB.

Useing imx6q-cubox-i.dtb for hummingboard carrier won't work. You need imx6q-hummingboard.dtb. In my environment I use mainline uboot build with mx6cuboxi target and distro-boot method. This way uboot identifies at which SolidRun imx6 device it is running and selects the appropriate DTB. IIRC Armbian uses also mainline uboot but boot.scr magic to select the DTB.

Post output of: cat /sys/kernel/debug/gpio and: cat /sys/firmware/devicetree/base/model with 5.x kernel running.

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.

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

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.

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.

This discussion is about USB Type-C DisplayPort Alternate Mode support on mainline kernel. It was introduced for Pinebook Pro with the referenced kernel patch. This thread is about Helios64 DTB making use of this funktionality. My discussion is about doing the same for NanoPC-T4. So, IMHO this belongs in a place where NanoPC-T4 is discussed with a title like "USB Type-C DisplayPort Alternate Mode Support for NanoPC-T4".

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

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.

The only difference here is the location of the persistent storage where the blob is located. I would prefer if all blobs I have to use be stored at a location I have control about, but this is not easy to get. In this way, I could at least control which blob is used and after a restart the device is in a known state. Where the blob is stored on the device, it is quite difficult to detect manipulations of malware that takes place at run time and then remains persitent.

If you care about the wifi blob, don't forget the blobs in SD-card-, EMMC-, Hardisk-, USB-stick-, Keyboard-controller, ... to have a complete system.

Proper dtb configuration and driver as build-in.

Mainline hardware acceleration does not work efficiently for X11 because it does not have a suitable ddx driver with the correct render node GPU and v4l2 mem2mem VPU support. I discussed my results in a thread that starts here with some follow-up posts while I examine it for myself.

You referenced the raw device by "/dev/mmcblk1" where MBR , u-boot and partitions reside. You need to reference a partition by "/dev/mmcblk1pX" where a suitable filesystem resides. Replace "X" with the number of the partition you want to check.