USB3 for rock64 ver 2

Troubleshooting
1

I’d like to use the USB3 port on my rock64 SBC. I’m testing with a known-good USB memory stick, and I’d like to use an external HDD once it works again.

Expected Behaviour: I’d like to be able to plug storage devices into the USB3 port on my SBC and have them recognized and ready to mount and exchange data. I’d like to be able to unplug them without crashing the system, even if they are not cleanly unmounted first.

Actual Behaviour: A Kingston USB3 flash drive gets partially recognized, but is not available to the usual software for data exchange.

My first hypothesis (of 2) is that this is a kernel issue. So I following the advice in this forum post (thread 6439, post 30). Something changed but the system does not yet work as expected. Supporting details:

  • DietPi version 8.5.1 [“Master”, thanks to MichaIng]
  • Distro version: bullseye
  • Kernel: Linux rock64 5.10.63-rockchip64 #21.08.2 SMP PREEMPT Wed Sep 8 10:57:23 UTC 2021 aarch64 GNU/Linux
  • SBC model: ROCK64 (aarch64) – board has “ver 2” printed on top
  • Power supply: 5V reasonable
  • SD card: 32 GB from some reliable maker [don’t want to shutdown and look]

I got the matching kernel and dtb from the packages linux-image-current-rockchip64 and linux-dtb-current-rockchip64 by explicitly selecting version 21.08.2. The following output looks rather encouraging:

$ lsusb
Bus 005 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 004 Device 002: ID 13fe:1d00 Kingston Technology Company Inc. DataTraveler 2.0 1GB/4GB Flash Drive / Patriot Xporter 4GB Flash Drive
Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

But the flash drive does not seem properly connected to the /dev/disk tree.
I say this for two reasons: first, a flash drive should be a block device,
but the system says otherwise:

$ file /dev/bus/usb/004/002
/dev/bus/usb/004/002: character special (189/385)

Second, I expect to see the flash drive as something like /dev/sda1, but instead the full story is like this:

$ tree /dev/disk
/dev/disk
├── by-id
│   ├── mmc-SD32G_0xda799673 -> ../../mmcblk0
│   ├── mmc-SD32G_0xda799673-part1 -> ../../mmcblk0p1
│   └── usb-_2301_Boot_Rom-0:0 -> ../../sda
├── by-partuuid
│   └── f7138353-01 -> ../../mmcblk0p1
├── by-path
│   ├── platform-ff500000.mmc -> ../../mmcblk0
│   ├── platform-ff500000.mmc-part1 -> ../../mmcblk0p1
│   └── platform-xhci-hcd.0.auto-usb-0:1:1.0-scsi-0:0:0:0 -> ../../sda
└── by-uuid
    └── 19e46d43-2ef4-45d3-be06-ceee5e2cb50f -> ../../mmcblk0p1

4 directories, 8 files

It looks like my flash drive has been mis-identified, either as some kind of “2301 Boot Rom” or maybe as a part that can be handled by “xhcd-hcd”. At this point I have run out of knowledge so completely that I don’t even know what to ask.

The results above suggest a second line of questions. Could my problem be somewhere in the udev system instead of the kernel? I have tried a few udevadm commands, but to be honest I don’t really know what to do with the results.

Thanks for taking the time to read this. Any suggestions would be welcome.

2

can you share following

lsblk -o name,fstype,label,size,ro,type,mountpoint,partuuid,uuid

Just to avoid a misunderstanding. We don’t do any kernel development. We use the original kernel provided by the base image. In your case it’s Armbian. Issues with the kernel would need to be fixed by these guys.

3

Thanks ever so much for answering! As requested …

$ sudo lsblk -o name,fstype,label,size,ro,type,mountpoint,partuuid,uuid
NAME        FSTYPE LABEL  SIZE RO TYPE MOUNTPOINT PARTUUID                             UUID
mtdblock0                  16M  0 disk                                                 
mmcblk0                  28.9G  0 disk                                                 
└─mmcblk0p1 ext4         28.9G  0 part /          f7138353-01                          19e46d43-2ef4-45d3-be06-ceee5e2cb50f

In case it’s relevant, here’s some more copy-paste of what happens when I unplug and then replug the flash drive. I unplugged after the first line of output and before the second. When this operation is completed, the lsusb command returns exactly the same info as above.

$ dmesg | tail -n 20
[253214.565145] usb 4-1: USB disconnect, device number 2
[253266.684547] usb 4-1: new high-speed USB device number 3 using xhci-hcd
[253266.833556] usb 4-1: New USB device found, idVendor=13fe, idProduct=1d00, bcdDevice= 1.10
[253266.833582] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[253266.833600] usb 4-1: Product: 2301 Boot Rom           
[253266.833617] usb 4-1: Manufacturer:                         
[253266.835830] usb-storage 4-1:1.0: USB Mass Storage device detected
[253266.837272] scsi host0: usb-storage 4-1:1.0
[253267.841016] scsi 0:0:0:0: Direct-Access              2301 Boot Rom    1.00 PQ: 0 ANSI: 0 CCS
[253267.841544] sd 0:0:0:0: Attached scsi generic sg0 type 0
[253267.889588] sd 0:0:0:0: [sda] Attached SCSI removable disk

I do understand that the kernels here come from Armbian. Indeed that was a good reason to raise my question here instead: I was hoping to hear from somebody who has managed to get the rock64 working without too much heroic low-level intervention!

Thanks again for taking an interest.

4

Should be this issue: ROCK64 | Latest kernel breaks USB3 · Issue #5378 · MichaIng/DietPi · GitHub
We really need to report this to Armbian even that ROCK64 is not officially supported anymore resp. has no maintainer on Armbian end: Rockchip - Armbian Community Forums

5

The first post in the cited Github issue offers a workaround that does not work for me. (Details in my original post.)

Now that this board is on Community Support over at Armbian, I’m not quite sure how to bring it to their attention. I’ll look into this over the next day or two and try to do something reasonable.

6

Unfortunately, from our end we are not able to solve this.

7

We can report it and hope that someone with more insights is having a look into it and able to provide a fix or workaround. Sadly I’m currently not aware of a proper kernel replacement. We could try with the generic Debian arm64 kernel, at least it has a device tree for ROCK64.

8

Reported: USB3 port on ROCK64 is not functional since Linux 5.15 - Rockchip - Armbian Community Forums

9

Thank you both for your help. I will watch the thread launched by MichaIng with interest.

10

Don’t expect miracles for a board without Armbian maintainer :wink:

11

@philip
I missed that you already tried to downgrade the kernel without success. Did you also try to downgrade the U-Boot package and flash it?

apt install linux-u-boot-rock64-current=21.08.2
. /usr/lib/u-boot/platform_install.sh
write_uboot_platform "$DIR" "$(lsblk -npo PKNAME "$G_ROOTFS_DEV")"

It’s strange since downgrading the kernel alone solved it in all other cases :thinking:.

Can you also try to add ,0x13fe:0x1d00:u to the usbstoragequirks line in /boot/armbianEnv.txt and reboot to disable UAS for this drive?

12

Good news: The ROCK64 has a maintainer clee at Armbian now. I’ll see if I can move the threat over: ROCK64 - Armbian Community Forums

13

@MichaIng, this might be just the kind of specialist knowledge I need! I had learned from online searches that the kernel and dtb had to be kept in sync, but I didn’t know the u-boot package had to be aligned as well.

There was a typo in the first line of your advice, that I found and fixed as follows:

$ sudo apt list -a linux-u-boot-rock64-current
$ sudo apt install linux-u-boot-rock64-current=21.08.1

For the next two lines of your advice, I took no chances and ran as root:

$ cd /usr/lib/u-boot/
$ sudo su -
# . platform_install.sh
# write_uboot_platform "$DIR" "$(lsblk -npo PKNAME "$G_ROOTFS_DEV")"

The bottom line took no time at all to run, but there was no error message, so I assume it did. After rebooting, all the diagnostics are the same as before. Unplugging the flash drive and replugging it later causes some kernel activity (seen in dmesg), but the final state is the same as before.

That’s the end of my report on the u-boot intervention; I’ll try the quirks next and respond separately about those.

14

U-Boot does usually not need to be kept in sync tightly. That’s the reason it’s not flashed automatically. But always good to try when something is not working. Sadly it didn’t help.

15

Unfortunately, the quirks intervention didn’t help either. Here for the record is my complete file /boot/armbianEnv.txt:

$ cat /boot/armbianEnv.txt 
verbosity=4
bootlogo=false
overlay_prefix=rockchip
rootdev=UUID=19e46d43-2ef4-45d3-be06-ceee5e2cb50f
rootfstype=ext4
usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u,0x13fe:0x1d00:u
extraargs=net.ifnames=0
docker_optimizations=off
console=none

But it’s great news that clee has picked up this challenge over at Armbian. @Jouilnar, does this mean we can go back to expecting miracles?

Thanks again for the help.

16

At least now there is someone which takes a look at bug reports and has more insights into this SBC’s Armbian firmware. There is no guarantee or ETA, those guys are all giving their best in their spare time, like us, but I’m optimistic that we’ll get further with this topic soon :slightly_smiling_face:.

1 Like
17

Good news / bad news:

Bad news: There was a mistake in my very first post. I was wrong about my “known good USB memory stick”. I tried older and older versions of Armbian without success until I thought of double-checking the flash drive. It doesn’t work anywhere. That means my original report is not a reliable source of information. I apologize for wasting your time.

Good news: A kernel downgrade makes the system recognize and mount some of my non-broken USB3 devices. I believe these are the commands I used:

sudo apt install linux-image-current-rockchip64=21.05.9
sudo apt install linux-dtb-current-rockchip64=21.05.9
sudo apt install linux-u-boot-rock64-current=21.05.1

sudo apt-mark hold linux-image-current-rockchip64
sudo apt-mark hold linux-dtb-current-rockchip64
sudo apt-mark hold linux-u-boot-rock64-current

Now I have this:

$ uname -a
Linux rock64 5.10.63-rockchip64 #21.05.9 SMP PREEMPT Wed Sep 8 09:06:59 UTC 2021 aarch64 GNU/Linux

Unfortunately I am out of time for more testing today. (My downgrade goes beyond the one originally suggested, but now we know that my experiences were unusual because of a broken testing setup. I would like to try some bisection to identify exactly which edition of the kernel first breaks USB3.) But here at least is one data point showing a configuration that works correctly.

Thanks again for looking at my issue.

18

Jep that fits our previous reports and workarounds. With Linux 5.10, USB3 works, with Linux 5.15, it doesn’t. The topic at Armbian forum has been moved to the new ROCK64’s “maintained” category, let’s hope someone finds a time for a fix soon.

The Linux 5.10 build is not such a great solution, respectively I hesitate to rebuild our images with the legacy kernel since it is affected by the Dirty Pipe vulnerability: Dirty Pipe vulnerability in Linux – DietPi Blog

19

The issue has been fixed in the build system, so next kernel package release will fix it: RK3328 fix USB3 5.15 by Tonymac32 · Pull Request #3957 · armbian/build · GitHub

If you want to thank the Armbian team: Donate – Armbian

But also many thanks to you guys for reporting and testing :heart:!