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.