The second USB port of NanoPI R4s is not working -- the logs were created with a USB disk inserted in port 2.

 

# lsusb -t

/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M

/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M

    |__ Port 1: Dev 3, If 0, Class=Vendor Specific Class, Driver=pl2303, 12M

 

If I remove and swap the USB devices:

 

# lsusb -t

/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M

    |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 5000M

/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M

 

Other users are reporting the same problem, including that it works with FriendlyCore and FriendlyWRT. I can test if needed to confirm the port is not dead.

 

https://github.com/armbian/build/pull/2877

Oh amazing, thank you. How long does it usually take to make it to an armbian release?

Depends on two things: Feedback from tony and testing. Latter can be done by yourself if you want. Checkout the PR, build a kernel package and install on your board.

I had the same issue. As a quick solution, I installed Armbian_21.05.1_Nanopi-r4s_focal_current_5.10.35.img.xz und updated the kernel to 5.11.18 and 5.12.6. With both versions, the second USB port is working now.

On 6/11/2021 at 2:10 AM, _MB_ said:

I had the same issue. As a quick solution, I installed Armbian_21.05.1_Nanopi-r4s_focal_current_5.10.35.img.xz und updated the kernel to 5.11.18 and 5.12.6. With both versions, the second USB port is working now.

 

Apologies -- how do I do that? I am well versed in Linux, but not familiar with Armbian.

49 minutes ago, Dan Podeanu said:

 

Apologies -- how do I do that? I am well versed in Linux, but not familiar with Armbian.

You can use the armbian-config tool. Check System -> Other

17 hours ago, Werner said:

You can use the armbian-config tool. Check System -> Other

Perfect, thank you.

 

# uname -a

Linux zen 5.11.18-rockchip64 #21.05.1 SMP PREEMPT Thu May 6 22:15:36 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux

 

# lsusb -t

/:  Bus 06.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M

/:  Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M

    |__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=rtl88x2bu, 480M

/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M

/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M

    |__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=pl2303, 12M

/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ohci-platform/1p, 12M

/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M

Unfortunately, I was a little euphoric about getting the second USB port working with the newer kernels. Today, after a lot of reboots and three days uptime, I noticed that my second USB port was not working any more. I do not know if it simply stopped working or was not available from the last boot. At least, rebooting brought it back again. I also did a lot of testing with moving the system to an USB SSD which also failed or succeeded to boot randomly (power issue excluded). So, be aware that my proposed solution to use kernel 5.11.18 or 5.12.6 is only a workaround and might not be stable.

Got it,  thank you. Do you think you could test https://github.com/armbian/build/pull/2877 ? 

13 minutes ago, Dan Podeanu said:

Do you think you could test https://github.com/armbian/build/pull/2877 ? 

 

We need someone to test:
"tested NanoPC T4 for DP altmode with TypeC"

then it can be merged.

merged.

5 hours ago, Werner said:

merged.

Great, thank you. When do you think it will make it to a release?

If there is no patch release in the mean time (there probably is) then it will be there with 21.08 which is planned for end of August.

For now feel free to checkout master and build your own kernel package for the board.

Hi...the most serious issue about the exceptionally appealing nanopi r4s generally is that nobody truly understands what it can do as such far. It's simply to new to tell, and keeping in mind that the basic center speed is one (promising) metric, the organization interconnect is an alternate one (PCIe or SOC local doesn't actually suggest up to which throughput it can keep up), nor if the producer wrecked concerning cooling, CPU scaling or board plan. On paper this gadget looks exceptionally pleasant, yet I've just seen a meager idea that it evidently can highway 1 GBit/s today (no clues what that involves however, no unpleasant CPU utilization, no sign if PPPoE was being used and no words about SQM or VPN), significantly more criticism will be required before it very well may be contrasted and the RPi4.d