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


ethDreamer
 Share

2 2
Go to solution Solved by Oleksii,

Recommended Posts

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.

Link to post
Share on other sites

Armbian is a community driven open source project. Do you like to contribute your code?

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? 

Link to post
Share on other sites

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.

Link to post
Share on other sites

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....

Link to post
Share on other sites

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.

Link to post
Share on other sites

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.

Link to post
Share on other sites

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

Link to post
Share on other sites

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.

Link to post
Share on other sites

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.

Link to post
Share on other sites

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

Link to post
Share on other sites

  • Solution
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.

Link to post
Share on other sites

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:

  1. 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";
            };
        };
    };
  2. Issue the command:
    armbian-add-overlay rockchip-usb-c-host.dts
  3. 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.

Link to post
Share on other sites

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! 

Link to post
Share on other sites

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.

 

 

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

2 2