nanoPC-T4 USB type-c port doesn't work with Buster current 5.4.31

ethDreamer · April 13, 2020

I've built everything into the kernel that I can think of:

Device Drivers --->
    [*] USB support -->
        [*] USB Type-C Support -->
             ** built everything other than alternative mode / display port drivers
    [*] PHY Subsystem --->
	...
        [*] Rockchip TYPEC PHY Driver

Nothing seems to get it working (other than using the legacy kernel). If I plug in a USB type-c ethernet adapter, the light stays on solid but nothing shows up under lsusb..

I'm not sure what else to try. Any help would be appreciated.

ot8 · August 29, 2020

The USB-C port is NOT working at all on 5.7.15 either. I'm specifically concerned about storage. Works fine with Ubuntu 18 and 4.4 kernel.

Igor · August 29, 2020

7 hours ago, ot8 said:

The USB-C port is NOT working at all on 5.7.15 either. I'm specifically concerned about storage. Works fine with Ubuntu 18 and 4.4 kernel.

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?

ot8 · August 29, 2020

1 hour ago, Igor said:

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?

I think you misunderstood the tone. It wasn't a demand, it was an observation.

Although ... it would be nice if there were some sort of release notes or FAQ entries for each build (Bionic, Buster, Focal and kernels 4.4.x, 5.x.x) outlining what works and what doesn't. Users could then make an educated decision beforehand, instead of discovering later that <hardware thing> doesn't work yet in a specific release/kernel.

Werner · August 29, 2020

2 minutes ago, ot8 said:

Although ... it would be nice if there were some sort of release notes or FAQ entries for each build (Bionic, Buster, Focal and kernels 4.4.x, 5.x.x) outlining what works and what doesn't. Users could then make an educated decision beforehand, instead of discovering later that <hardware thing> doesn't work yet in a specific release/kernel.

Sure that would be nice. But stuff is changing frequently and there are simply not enough ressources to keep track and test each and every feature of each and every board over and over....

Igor · August 29, 2020

34 minutes ago, ot8 said:

it would be nice

For start cover what you have now. We invest 20-30-50h per day and when its release time, I have to stop all my other activities (work for food, dealing with kids and supreme commander) for several days.

https://www.armbian.com/get-involved/
Doing whatever useful for the project helps solving this problem.

ethDreamer · August 30, 2020

On 8/29/2020 at 7:56 AM, Igor said:

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?

I can understand why you're frustrated doing all this for (essentially) free. Let me see what I can do to help. Can you answer some questions for me?

I do know C and I am a software engineer, but I've never worked with the kernel before and my low level/device driver knowledge isn't so good. Is the learning curve for this type of work too steep to have this be my first project?

> It's expensive work

If it is too difficult to learn, do you have any idea how expensive this would be?

I do appreciate you keeping the lights on man. I know this project wouldn't exist without your help.

RussianNeuroMancer · September 2, 2020

On 4/13/2020 at 9:32 AM, ethDreamer said:

I'm not sure what else to try. Any help would be appreciated.

Please try DisplayPort kernel for NanoPC-T4 published here. DisplayPort function does not work, but there is good chances that at least Ethernet adapters or flash-drives could work. Patches used for building this kernel is published here, so please redirect your feedback regarding this kernel to Oleksii thread.

Oleksii · October 18, 2020

On 9/2/2020 at 4:02 PM, RussianNeuroMancer said:

Please try DisplayPort kernel for NanoPC-T4 published here. DisplayPort function does not work, but there is good chances that at least Ethernet adapters or flash-drives could work. Patches used for building this kernel is published here, so please redirect your feedback regarding this kernel to Oleksii thread.

USB Type-C port will work as USB 3.0 port in HOST ONLY mode (which, as it appeared, is enough for the vast majority). And the only needed and sufficient change for this:

&usbdrd_dwc3_0 {
dr_mode = "host";
};

is to be added to the DTB

tobefond · October 21, 2020

Am 29.8.2020 um 15:41 schrieb ot8:

I think you misunderstood the tone. It wasn't a demand, it was an observation.

Although ... it would be nice if there were some sort of release notes or FAQ entries for each build (Bionic, Buster, Focal and kernels 4.4.x, 5.x.x) outlining what works and what doesn't. Users could then make an educated decision beforehand, instead of discovering later that <hardware thing> doesn't work yet in a specific release/kernel.

Same problem for me: I upgraded my NanoPC T4 and spent a lot of time to configure everything. At the end I noticed USB-C is not working to connect my essential backup drive. I spent many hours for nothing, because I thought a "stable" release means that at least basic I/O functionality was tested. I understand that testing takes manpower and money. But if it is missing the releases should me called "stable" for a referenced device. I do not know how many other users run into the same problem and waste their time.

NicoD · October 21, 2020

1 hour ago, tobefond said:

Same problem for me: I upgraded my NanoPC T4 and spent a lot of time to configure everything. At the end I noticed USB-C is not working to connect my essential backup drive. I spent many hours for nothing, because I thought a "stable" release means that at least basic I/O functionality was tested. I understand that testing takes manpower and money. But if it is missing the releases should me called "stable" for a referenced device. I do not know how many other users run into the same problem and waste their time.

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.

tobefond · October 21, 2020

vor 2 Stunden schrieb NicoD:

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.

Buster Server 5.8y on NanoPC T4

Oleksii · October 24, 2020

On 10/21/2020 at 4:41 PM, tobefond said:

Same problem for me: I upgraded my NanoPC T4 and spent a lot of time to configure everything. At the end I noticed USB-C is not working to connect my essential backup drive. I spent many hours for nothing, because I thought a "stable" release means that at least basic I/O functionality was tested. I understand that testing takes manpower and money. But if it is missing the releases should me called "stable" for a referenced device. I do not know how many other users run into the same problem and waste their time.

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.

Akeo · November 1, 2020

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.

Oleksii · November 2, 2020

20 hours ago, Akeo said:

Thanks to @Oleksii for figuring out that the issue is that the USB-C controller is set to OTG mode rather than host mode.

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.

Good work! Although, it solves some problem for you, I want to mention additionally: what you did and what I suggested - is just a very specific workaround rather than permanent fix . This port configuration is set to otg by default in the master (board family) dtb file purposely, and imho this is right, not a mistake anyway. Because this board supports Dual Mode on USB Type-C port, if you have proper support in all concerned drivers and enabled Dual Mode in kernel, of course. Real actual role of the port should be determined by the system automatically, based on the negotiation with other party (I purposely simplify things a lot ). This port capabilities detection and further toggling is performed by the driver of a dedicated programmable PD chip (FUSB302), which then should notify all other concerned underlaying drivers about the new role decision. My conclusion, after some intensive research performed, makes me confident to state, that current mainline fusb302 driver still misses a lot of desired functionality to support needed interaction with dwc3 driver e.g. in a right fashion If there are experts around who may argue and confirm that I'm not right, I'll be only happy to hear this!

Akeo · November 2, 2020

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.

Erica · June 16, 2023

On 10/18/2020 at 11:59 AM, Oleksii said:

Hello,

I am running jammy from February and I've noticed that neither of the usb c or 3 ports work.

This thread is not very clear as to whether there are working solutions or which one to use.

Is it true that a dts overlay with the following would turn it on?

I'm still not very experienced with dts stuff but I think I could figure that out.

Thank you,

Erica

On 10/18/2020 at 11:59 AM, Oleksii said:

USB Type-C port will work as USB 3.0 port in HOST ONLY mode (which, as it appeared, is enough for the vast majority). And the only needed and sufficient change for this:

&usbdrd_dwc3_0 {
dr_mode = "host";
};

is to be added to the DTB

Erica · June 16, 2023

I find it confusing that there was a PR for this, but that it still seems to be a problem.

Sign In

nanoPC-T4 USB type-c port doesn't work with Buster current 5.4.31

Recommended Posts

ethDreamer

ot8

Igor

ot8

Werner

Igor

ethDreamer

RussianNeuroMancer

Oleksii

tobefond

NicoD

tobefond

Oleksii

Akeo

Oleksii

Akeo

Erica

Erica

Join the conversation

Similar Content

Forums

My Activity Streams

Download

Store

Important Information