Re: dwc_otg USB on Rock64
- In reply to: Andriy Gapon : "dwc_otg USB on Rock64"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sun, 25 May 2025 02:59:29 UTC
On May 24, 2025, at 05:18, Andriy Gapon <avg@FreeBSD.org> wrote:
> I am curious if anyone has the OTG (upper USB2) port working on Rock64.
> I do not want any fancy from it, just have it work in host mode.
> So far, not much luck.
> I've tried it only umass devices and either drives fail to probe or get detached shortly after attaching.
[It has been a very long time since the Rock64 has
been powered. I'm using one of my general aarch64
USB3 boot media below, not something Rock64
specific.]
While I can boot from the USB3 port, including via
USB3 media, I can not boot from the upper USB2 port.
It hangs after:
scanning bus usb@ff580000 for devices...
is printed.
After booting via USB3, however, I plugged in a different drive:
ugen1.2: <Samsung PSSD T7 Touch> at usbus1
umass1 on uhub3
umass1: <Samsung PSSD T7 Touch, class 0/0, rev 2.10/1.00, addr 2> on usbus1
da1 at umass-sim1 bus 1 scbus1 target 0 lun 0
da1: <Samsung PSSD T7 Touch 0> Fixed Direct Access SPC-4 SCSI device
da1: Serial Number S5K5NJ0R107042P
da1: 40.000MB/s transfers
da1: 953869MB (1953525168 512 byte sectors)
da1: quirks=0x2<NO_6_BYTE>
At least for just sitting there, nothing more has
happened. (Later below, I show a little activity.)
The U-Boot is one I got working last year that I've
not touched since:
U-Boot TPL 2024.04 (Jun 13 2024 - 01:20:13)
LPDDR3, 800MHz
BW=32 Col=11 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=4096MB
Trying to boot from BOOTROM
Returning to boot ROM...
U-Boot SPL 2024.04 (Jun 13 2024 - 01:20:13 +0000)
Trying to boot from MMC1
NOTICE: BL31: v2.10.4(release):
NOTICE: BL31: Built : 16:08:38, Jun 11 2024
NOTICE: BL31:Rockchip release version: v1.2
U-Boot 2024.04 (Jun 13 2024 - 01:20:13 +0000)
Model: Pine64 Rock64
DRAM: 4 GiB
PMIC: RK8050 (on=0x40, off=0x00)
Core: 236 devices, 28 uclasses, devicetree: separate
MMC: mmc@ff500000: 1, mmc@ff520000: 0
Loading Environment from MMC... *** Warning - bad CRC, using default environment
. . .
It deals with the USB3 port, avoiding needing the
historical special procedures for having the world
there for booted operation.
The kernel and world are official PkgBase ones,
so an officially built GENERIC-NODEBUG kernel is
in use, despite the context being main [so: 15
at this point].
uname -apKU
FreeBSD aarch64-main-pkgs 15.0-CURRENT FreeBSD 15.0-CURRENT main-n277335-7fa19ee28c90 GENERIC-NODEBUG arm64 aarch64 1500043 1500043
# gpart show -pl
=> 40 62333872 mmcsd0 GPT (30G)
40 32728 - free - (16M)
32768 524288 mmcsd0p1 Rock64Empty (256M)
557056 61776856 - free - (29G)
=> 34 1875384941 da0 GPT (894G)
34 32734 - free - (16M)
32768 501760 da0p1 PkgBaseEFI (245M)
534528 20971520 da0p2 PkgBaseSwp10 (10G)
21506048 29360128 da0p3 PkgBaseSwp14 (14G)
50866176 33554432 da0p4 PkgBaseSwp16 (16G)
84420608 67108864 da0p5 PkgBaseSwp32 (32G)
151529472 96468992 da0p6 PkgBaseSwp46 (46G)
247998464 268435456 da0p7 PkgBaseSwp128 (128G)
516433920 7340032 da0p8 PkgBaseSwp3p5 (3.5G)
523773952 13631488 da0p10 PkgBaseSwp6p5 (6.5G)
537405440 1337979528 da0p9 PkgBaseUFS (638G)
1875384968 7 - free - (3.5K)
=> 40 1953525088 da1 GPT (932G)
40 20440 - free - (10M)
20480 512000 da1p1 RPi4EFI (250M)
532480 2048 - free - (1.0M)
534528 7131136 da1p2 Rock64swp2 (3.4G)
7665664 1257472 - free - (614M)
8923136 23068672 da1p3 Rock64swp3 (11G)
31991808 2097152 - free - (1.0G)
34088960 33554432 da1p4 8gRPi4swap (16G)
67643392 1740636160 da1p5 Rock64root (830G)
1808279552 145245576 - free - (69G)
The mmcsd0 has the U-Boot on it. PkgBaseEFI on da0
was used.
The da1 media is a drive that has not been kept up
to date for my context. da1 is also a USB3 capable
drive that is USB2 compatible. It gets its power
from the USB connection. (da0 is a powered drive,
a U.2 Optane via an USB3.2 Gen 2 capable adapter.)
# mount -onoatime /dev/gpt/Rock64root /mnt # so da1
#
# strings /mnt/boot/kernel/kernel | grep 15.0-CURRENT
@(#)FreeBSD 15.0-CURRENT #107 main-n268363-8b67c670a49b-dirty: Sun Feb 18 09:49:56 UTC 2024
FreeBSD 15.0-CURRENT #107 main-n268363-8b67c670a49b-dirty: Sun Feb 18 09:49:56 UTC 2024
15.0-CURRENT
# uptime
7:45PM up 47 mins, 1 user, load averages: 0.10, 0.05, 0.06
#
I'll note that historically Rock64's have not been
uniform in some ways. FreeBSD and basic Ethernet
worked okay for me but not for some others, as I
understand. Mine was generally an older vintage
Rock64 when such issues came up, if I remember
right.
> Here is a typical scenario:
> May 19 09:02:15 rock64b kernel: usb_msc_auto_quirk: UQ_MSC_NO_PREVENT_ALLOW set for USB mass storage device USBest Technology USB Mass Storage Device (0x1307:0x0163)
> May 19 09:02:16 rock64b kernel: usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored)
> May 19 09:02:26 rock64b kernel: usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT
>
> May 19 09:02:27 rock64b kernel: ugen0.2: <USBest Technology USB Mass Storage Device> at usbus0
> May 19 09:02:27 rock64b kernel: umass0 on uhub3
> May 19 09:02:27 rock64b kernel: umass0: <USBest Technology USB Mass Storage Device, class 0/0, rev 2.00/1.00, addr 2> on usbus0
> May 19 09:02:27 rock64b kernel: umass0: SCSI over Bulk-Only; quirks = 0x8000<NO_PREVENT_ALLOW>
> May 19 09:02:27 rock64b kernel: umass0:2:0: Attached to scbus2
> May 19 09:02:27 rock64b kernel: da0 at umass-sim0 bus 0 scbus2 target 0 lun 0
> May 19 09:02:27 rock64b kernel: da0: <JetFlash TS4GJFV60 0.00> Removable Direct Access SCSI-2 device
> May 19 09:02:27 rock64b kernel: da0: Serial Number 2000cd60122411
> May 19 09:02:27 rock64b kernel: da0: 40.000MB/s transfers
> May 19 09:02:27 rock64b kernel: da0: 3935MB (8060927 512 byte sectors)
> May 19 09:02:27 rock64b kernel: da0: quirks=0x2<NO_6_BYTE>
>
> May 19 09:02:27 rock64b kernel: ugen0.2: <USBest Technology USB Mass Storage Device> at usbus0 (disconnected)
> May 19 09:02:27 rock64b kernel: umass0: at uhub3, port 1, addr 2 (disconnected)
> May 19 09:02:27 rock64b kernel: (da0:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 7a ff fe 00 00 01 00
> May 19 09:02:27 rock64b kernel: (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error
> May 19 09:02:27 rock64b kernel: (da0:umass-sim0:0:0:0): Retrying command, 3 more tries remain
> May 19 09:02:27 rock64b kernel: da0 at umass-sim0 bus 0 scbus2 target 0 lun 0
> May 19 09:02:27 rock64b kernel: da0: <JetFlash TS4GJFV60 0.00> s/n 2000cd60122411 detached
> May 19 09:02:27 rock64b kernel: g_dev_taste: g_dev_taste(da0) failed to g_attach, error=6
> May 19 09:02:27 rock64b kernel: (da0:umass-sim0:0:0:0): Periph destroyed
> May 19 09:02:27 rock64b kernel: umass0: detached
>
> Note a 10 second delay between "set address failed" and "getting device descriptor at addr 2 failed".
> Nevertheless umass0 gets attached and da0 gets correctly probed.
> But right after that umass0 gets detached.
>
> I also tried snooping with usbdump and this is what I see:
>
> 17:05:16.390793 usbus1.2 SUBM-BULK-EP=00000001,SPD=HIGH,NFR=1,SLEN=32,IVAL=0
> frame[0] WRITE 31 bytes
> 0000 55 53 42 43 08 00 00 00 00 02 00 00 80 00 0A 28 |USBC...........(|
> 0010 00 00 7A FF FE 00 00 01 00 00 00 00 00 00 00 -- |..z............ |
> 17:05:16.390982 usbus1.2 DONE-BULK-EP=00000001,SPD=HIGH,NFR=1,SLEN=0,IVAL=0,ERR=0
> frame[0] WRITE 31 bytes
> 17:05:16.391009 usbus1.2 SUBM-BULK-EP=00000082,SPD=HIGH,NFR=1,SLEN=0,IVAL=0
> frame[0] READ 512 bytes
> 17:05:16.401376 usbus1.2 DONE-BULK-EP=00000082,SPD=HIGH,NFR=0,SLEN=0,IVAL=0,ERR=CANCELLED
>
> This corresponds to host sending <<READ(10). CDB: 28 00 00 7a ff fe 00 00 01 00>> command that's reported in the log.
> Then there is ERR=CANCELLED when trying to get data from the command (READ 512 bytes).
> Not sure if that error is a consequence or a cause of the disconnect.
>
> Any help / hints / insights / stories are appreciated.
===
Mark Millard
marklmi at yahoo.com