Oleksii

Yes, I fully agree with your analysis that the proper solution is to have upstream kernel properly fixed to perform autonegotiation. But in the absence of someone actively working on that, and considering that many NanoPC-T4 users are looking for a solution that'll let them use USB-C in host mode, we might as well provide a workaround through an overlay for the time being. I have therefore submitted a Pull Request for this in https://github.com/armbian/build/pull/2299.
 
 

Thanks to @Oleksii for figuring out that the issue is that the USB-C controller is set to OTG mode rather than host mode.
 
This is illustrated by the rk3399-nanopc-t4.dtb which, when decompiled, contains the following:
 
usb@fe800000 { compatible = "rockchip,rk3399-dwc3"; #address-cells = < 0x02 >; #size-cells = < 0x02 >; ranges; clocks = < 0x08 0x81 0x08 0x83 0x08 0xf6 0x08 0xf8 0x08 0xf4 0x08 0xf9 >; clock-names = "ref_clk\0suspend_clk\0bus_clk\0aclk_usb3_rksoc_axi_perf\0aclk_usb3\0grf_clk"; resets = < 0x08 0x125 >; reset-names = "usb3-otg"; status = "okay"; phandle = < 0xd6 >; usb@fe800000 { compatible = "snps,dwc3"; reg = < 0x00 0xfe800000 0x00 0x100000 >; interrupts = < 0x00 0x69 0x04 0x00 >; clocks = < 0x08 0x81 0x08 0xf6 0x08 0x83 >; clock-names = "ref\0bus_early\0suspend"; dr_mode = "otg"; phys = < 0x33 0x34 >; phy-names = "usb2-phy\0usb3-phy"; phy_type = "utmi_wide"; snps,dis_enblslpm_quirk; snps,dis-u2-freeclk-exists-quirk; snps,dis_u2_susphy_quirk; snps,dis-del-phy-power-chg-quirk; snps,dis-tx-ipgap-linecheck-quirk; power-domains = < 0x1a 0x18 >; status = "okay"; phandle = < 0xd7 >; }; };  
So, as @Oleksii pointed out, dr_mode is set to "otg" rather than "host", and that is why the USB-C port is treated as a USB peripheral rather than a USB host, and why you can't get any device plugged onto that port to be recognized.
 
The solution is fairly simple:
Create a rockchip-usb-c-host.dts file in /boot/dtb/rockchip/overlay with the following content: /dts-v1/; /plugin/; / { compatible = "rockchip,rk3399"; fragment@0 { target = <&usbdrd_dwc3_0>; __overlay__ { dr_mode = "host"; }; }; }; Issue the command: armbian-add-overlay rockchip-usb-c-host.dts Reboot as asked. Devices plugged into the USB-C port should now be detected. You can also verify that the USB-C port is set to host mode by issuing: cat /sys/firmware/devicetree/base/usb@fe800000/usb@fe800000/dr_mode which should now report host rather than otg.
I'll see if I can create a Pull Request to generate this .dtbo in https://github.com/armbian/build/blob/master/patch/kernel/rockchip64-dev/general-rockchip-overlays.patch.

How come, USB Type-C port will magically start working if there is no proper support for this in the mainline kernel for this board family? Even if kernel version is declared as stable, this doesn't mean that 100% of the "expected" functionality will work on 100% of the platforms. If you decided to base your work on the mainline kernel versions for this board, you should already know about hardware limitations related to the presence of proprietary vendor's drivers that are not really maintained by the vendor.

You waste our time not giving us the data we need to be able to help.
sudo armbianmonitor -u
What image? What kernel?

Mainline is still in development. Things are added, and other things break. That's just a fact of life.
We can't test every single thing.
Use Legacy if it fits your goal. Thank you for wasting my time too.
If you're not happy buy an x86 sbc and buy Windows for it. Then go complain to Microsoft like that. Please.

According to the support contract, this is not a problem.
 
Porting features from fixed private to the mainline kernel is far from cheap and simple. Its expensive work which you cover in exactly 0%. Hire someone to do this job and share the work. Why would we need to do that? 

Hello, nanopc t4 folks,
 
Some, not so long time ago, I worked on fusb302.ko driver and device tree improvements in order to make USB Type-C port working properly in the mainline 5.* kernel. I managed to get DisplayPort over type-C + some general type-c handling improved before my board simply died. Unfortunately, I was not able to finish all the planned work and cannot continue further  However, I guess, working DP is already fairly good achievement that might be interesting for many of us. Hereby, I want to publish some patches to the mainline!!! driver and device tree that add missing functionality, so one can get DP+type-C working on NanoPC T4 (and all RK3399 based boards with Fairchild FUSB302 chip for PD with relatively small DT adjustments). I would be very happy if results of my work can be helpful to others and extremely happy if there any volunteers, who are willing to continue work on this subject. My primary goal was to contribute to Armbian, first of all, with a potential mainline repo contribution. What was added:
Extcon notifications support (type-c related cables) in the stock fusb302 driver (developed by Google folks, but also used by Intel  if I understand correctly) DisplayPort altmode is registered automatically, if device tree has proper modelling for that DisplayPort altmode is entered as soon as DP cable connection is detected (both DP+USB3.0 and DP only pin assignments are supported)  DisplayPort altmode is handled by the unified DP altmode driver rather than custom out-of-tree PD chip driver "connector" node modelling in the device tree according to the mainline kernel docs and modern requirements fusb node phandle is still specified as extcon source for Rockchip's proprietary drivers, however, last can be easily adjusted to resolve extcon directly from connector node link (as soon as extcon property is declared as deprecated for all new development). fusb302 driver is now correctly linked to dwc3 driver which provides role_switch functionality (+1 step to correct "Dual Role" mode handling based on the cable detection). This also eliminates annoying error message in the boot log: "OF: graph: no port node found in /i2c@ff3d0000/typec-portc@22"  
Please, also notice that type-c mode is forced to Host as in the most of rk3399 based SBC dtbs presently. This is rather a workaround for such boards, than a permanent solution, until all necessary bits are developed for correct role switching in the drivers. I kindly ask some NanoPC T4 owners to build mainline kernel with my patches and test whether expected functionality also works for you. Those patches apply to linux kernel since 5.6 when I started to work, but should also apply to way earlier versions according to my brief analysis of kernel commits history.
 
fusb302-add-extcon.patch rk3399-nanopc-t4-type-c-modeling.patch

If you are still interested in Type-C for mainline kernels. My patches at least explain what is missing in the present drivers and why this magic dr_mode = "host" is specified everywhere in the mainline dtbs

A bit of offtopic, but if anyone is interested Hardkernel is more open about RMA.

Just my perosonal cents:
I got some NanoPis from FriendlyARM with Allwinner-Chips like H2+, H3 , H5 and A64 and they do work alll very well and since years 24/7 - but I got some Rockchip devices from other companys and they are the "black sheeps" of my SBCs - so Iam do not buy Rockchip-devices anymore.
So when try to buy Allwinner devices from FriendlyARM - but isnt that easy anymore without new H5-devices and no real successor in the near future

One of my NanoPC T4 also died a four months ago for no apparent reason, some symptoms was similar to description from Oleksii post. Initially it always printed long stack trace to serial console during rockchip_drm initialization, and then reboot on emmc initialization attempt. Later it stopped booting from emmc as if it's empty, but attempts to boot from microsd always lead to same outcome - boot loop. And finally it stopped even trying to boot from microsd with only red light.
 
FriendlyARM send replacement for this board, but making them doing so certainly wasn't easy - when all troubleshooting steps doesn't help, they decided to stop answering until I tried to place a new order via sales e-mail and asked them to put replacement board into this order.

Mainline kernel is of fairly decent quality in regard to most popular RK3399 boards. All critical components work fine and have really good support. But something, which makes such boards outstanding, still doesn't work in 5.*  It is normal for the situation when vendor's developers are locked inside of their private sandboxes (they call it SDK, LTS branch whatever, we call it simpler - "legacy") and do not really see the world is bigger outside  . However, I have good news for those who own RK3399 based SBCs with Fairchild FUSB302 controller responsible for type-c handling and power delivery protocol. This chip is widely popular, so there are some other users of its driver in the kernel and driver itself is very well elaborated (IMHO again). But it still misses many things that we, Rockchip+FUSB302 owners, really need. There is absolutely no need to write new drivers or wait when developers from Rockchip will do it (they won't). The driver deserves some extension and we will get both DisplayPort and properly working Type-C port (not statically fixed to USB3 host in the dtb, as many present maintainers do for their boards, but real DRD with role switching based on cable detection). I was working on this subject for two (or even three of last weeks, don't remember exactly anymore  ) and managed to fill this gap and get working DP on this "silently abandoned" port. Dual Role support for Type-C was in progress, but it can be solved too indeed. Right now, I have neither technical possibility nor motivation nor even time to continue anymore. The best what I can do is to recover what I've lost and handover my patches to some other volunteers who can/want to continue development (but even this needs a lot of time). My plan A was to deliver those features to my lovely Armbian community, and then try pushing it upstream.

Oh,I fixed this problem spend 2 weeks,I finally heard sound from 3.5 mm jack (this jack is OMTP otherwise need keep press headphone button)
 
I see this topic,and I compair https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/sound/soc/codecs/rt5640.c and https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/sound/soc/codecs/rt5651.c,this rt5651 not enable mclk and orangepi4"s rt5651 linked i2s1,the i2s1's SCLK_I2S_8CH parent not SCLK_I2S1_8CH defult and need set alsamixer in following(also use alsactl save this alsamixer state):
amixer set 'HPO L' on amixer set 'HPO R' on amixer set 'HPOVOL L' on amixer set 'HPOVOL R' on amixer set 'HPO MIX HPVOL' on amixer set 'OUT MIXL DAC L1' on amixer set 'OUT MIXR DAC R1' on amixer set 'Stereo DAC MIXL DAC L1' on amixer set 'Stereo DAC MIXR DAC R1' on And I not familiar with electronics,I did some patch and hope this can help armbian fix 
fix-i2s1-clk.patch orangepi4-rt5651.patch orangepi4-i2s_8ch_mclk.dts
Armbian applied this patch to 'Armbian build system' and with minor tweaks,you can use it by 'Armbian build system' latest branch.

It is not so obvious  I only consider the state in the mainline kernel as a reference (because I decided for myself to track changes since 5.* only). And I see that USB Type-C controller changes its state from "host" to "gadget" and almost immediately powers off during the boot. It should be correctly handled automatically by the driver on this board according to my understanding. And forcing to host mode is imho just a workaround for some issue in the current driver (or some other problems in device tree).

Strange and obscure problem. With the latest patches, I have audio output working through the codec rt5651. But only with a 5.2.8 core.
I used these fixes in core 5.4.35. But no sound device rt5651 is created. At the same time, everything is normal in the log. The codec driver is connecting successfully.
 
 
Good news. There was an error in dts file patch. You must use the name "realtek" instead of "rockchip" in the node rt5651: rt5651@1a. In this case, the codec driver module will be used successfully. Otherwise, the module will not load automatically.
 
&i2c1 { clock-frequency = <200000>; i2c-scl-rising-time-ns = <150>; i2c-scl-falling-time-ns = <30>; status = "okay"; rt5651: rt5651@1a { #sound-dai-cells = <0>; compatible = "realtek,rt5651"; reg = <0x1a>; clocks = <&cru SCLK_I2S_8CH_OUT>; clock-names = "mclk"; pinctrl-names = "default"; pinctrl-0 = <&i2s_8ch_mclk>; }; };  

apt update && apt -y upgrade  
1. armbian-config -> software -> softy
 
Home Assistant smart home suite (https://www.home-assistant.io/hassio) OpenHAB2 smart home suite (https://www.openhab.org)  
Bug fixes:
 
Syncthing ZSH Internet detection also works behind proxy
Cosmetical fixes:
 
UrBackup Transmission  
Removed:
 
Exagear (EOL)  
2. armbian-config -> personal -> mirror
 
New mirror http://mirrors.dotsrc.org/armbian-apt/ & http://mirrors.dotsrc.org/armbian-dl/

Looks like we got an upstream DT for the T4: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/arch/arm64/boot/dts/rockchip?id=e7a095908227fb3ccc86d001d9e13c9ae2bef8e6

Just for reference, a simplified version that works with both linux 4.4 and the linux 4.20 kernel:
 
# make the PWM port available to sysfs $ echo 0 | sudo tee /sys/class/pwm/pwmchip1/export 0 # set the PWM-freq to 25kHz (=40000ns) $ echo 40000 | sudo tee /sys/class/pwm/pwmchip1/pwm0/period 40000 # enable the PWM $ echo 1 | sudo tee /sys/class/pwm/pwmchip1/pwm0/enable 1 It starts the fan at fullspeed as by default the polarity of the PWM is inversed: duty_cycle of "0" == "always on".
$ cat /sys/class/pwm/pwmchip1/pwm0/polarity inversed $ cat /sys/class/pwm/pwmchip1/pwm0/duty_cycle 0 To slow the fan down with inversed polarity one needs to bring the duty_cycle close to the "period" set before
$ echo 35000 | sudo tee /sys/class/pwm/pwmchip1/pwm0/duty_cycle 35000  

After removing the noise from the input-data, I now got quite reasonable RPM values for the Noctua NF A14:
 
RPM per duty_cycle [ns] duty_cycle RPM 180 158 200 476 250 637 300 938 400 1111 500 1200 2000 1251  
Below 180ns the fan stops, above 500ns it doesn't really increase anymore.
 
fan.svg

I have the same problem, just connected a 2 pin 5V from the casual pins instead of using the fan controller designed for the board. I Also mentioned in one of my emails to FriendlyElec with another bunch of questions, yet that question remained unanswered. If you find a fan with a connector that fits, please publish it so others like me can also use the solution.

I think you would have to wire it yourself tbh.
 
Connector wise your looking for http://www.hobbytronics.co.uk/cables-connectors/polarized-connector-housing a 3 pin one.  Dont forget the crimp pins and all. Im assuming this is the right size for the pins but you will need to check the pin size. I dont have this board so cant be certain on the pin size.