RockPro64 - spi don't boot from usb3

[bullet64]

1. Flash u-boot to spi
2. Flash image 0.7.9 (bionic-minimal) to an Samsung 860 PRO 256GB
3. Boot from USB2 - works fine!
4. Boot from USB3 - don't work

Log from boot on usb3 -> https://pastebin.com/KaVg2CN0

[bullet64]

Update:

An USB-Stick works perfect and boot on USB3 slot.

But all my USB3-to-SATA-Adapter (3) failed. Not detected by u-boot

https://pastebin.com/g3T4s3Tf

[bullet64]

Ok, i got it working.

With an extern usb3 hub (with power supply) my Samsung 860 Pro 256 GB is booting from USB3-Port.

https://pastebin.com/D8DB9dnV

I am no coder or linux guru, so i don't know what cause this problem.

Power problem?
Timing problem?

I think it's a timing problem, ssd will get too late power.

Sry, for my english.

[XDA-Bam]

I can confirm this issue. Booting from SPI using only an SSD in external USB3 enclosure attached to any USB port (2.0 or 3.0) fails most of the time. However, in my case it doesn't fail every time. Roughly one out of four tries, it works. If it works, systems seems to be stable and reliable (tested up to 1 day of runtime).

Is there any progress on this bug? Do you need additional information or logs?

[karlskewes]

I've noticed the same irregular booting with 3xRock64's using Apacer SSD on USB3 port with the Pine64 adapter cable
No external power to SSD's which looks like the problem above.
The red LED doesn't light up.
If power off/on or toggle reset switch, rock64 will come up after 1+ attempts (varies).
Generally can ping the host, but can't SSH which matches @bullet64 first pastebin link above (rock64 retrieves IP address via DHCP then stops).

[karlskewes]

TLDR; SSD doesn't boot? Try powering SSD drive externally per bullet64 above.
Updated: Or use USB2 port which WFM, albeit slower. Also it looks like later kernels might have a fix for this, see pine64 forums.

So, I think I have a thirsty/different SSD drive.
I ran below command to ssh and reboot each Rock64 in a loop in tmux panes so I could monitor all 3 rock64's.
while true; do date; ssh -o ConnectTimeout=60 rock64@k8s-w-00 sudo reboot; sleep 10s; done
Then I swapped around PSU, USB->SATA and finally SSD drives.
Moving the SSD drive between rock64's resulted in the faulty boot behaviour also moving.

Plugging the 'thirsty/different' SSD drive into a powered USB hub (not the usb->sata adapter port) resulted in consistent booting.
So I suspect there's a power draw threshhold that's been exceeded per bullet64 above.

I also noticed that during this testing boot behaviour across the rock64's was different.
Sometimes the red LED takes a while to come on after a power up/reboot and any delay indicated less than quick or potentially successful boot behaviour.

My Rock64's tower case doesn't allow access to the serial pins so I perhaps did this testing the hard way. Off to get/make a multi-head power supply..

[bullet64]

New USB-Stick. Works fine on active hub with kernel 4.4.x

rock64@rockpro64:~$ dmesg | grep -E "usb 4.1.1"
[ 3.495435] usb 4-1.1: new SuperSpeed USB device number 3 using xhci-hcd
[ 3.519860] usb 4-1.1: New USB device found, idVendor=1b1c, idProduct=1a0e
[ 3.532552] usb 4-1.1: New USB device strings: Mfr=2, Product=3, SerialNumber=1
[ 3.545381] usb 4-1.1: Product: Voyager GTX
[ 3.557813] usb 4-1.1: Manufacturer: Corsair
[ 3.567008] usb 4-1.1: SerialNumber: 511180710xxxxxxxxxxxx

With kernel 4.18.x sys don't boot.

[ 3.847940] usb 8-1: new SuperSpeed Gen 1 USB device number 2 using xhci-hcd
[ 3.895147] hub 8-1:1.0: USB hub found
[ 3.895345] hub 8-1:1.0: 4 ports detected
[ 3.911572] Console: switching to colour frame buffer device 240x67
[ 3.944993] rockchip-drm display-subsystem: fb0: frame buffer device
[ 3.960062] [drm] Initialized rockchip 1.0.0 20140818 for display-subsystem 0
Begin: Loading essential drivers ... done.
Begin: Running /scripts/init-premount ... done.
Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done.
Begin: Running /scripts/local-premount ... done.
[ 4.771874] usb 8-1.1: new SuperSpeed Gen 1 USB device number 3 using xhci-hd
[ 4.812501] scsi host0: uas
[ 4.813366] scsi 0:0:0:0: Direct-Access Corsair Voyager GTX 0 P6
[ 4.815496] sd 0:0:0:0: [sda] 250069680 512-byte logical blocks: (128 GB/119)
[ 4.816013] usbcore: registered new interface driver uas
Begin: Waiting for root file system ... Begin: Running /scripts/local-block ....
done.
[ 35.847771] sd 0:0:0:0: tag#0 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD
[ 35.848629] sd 0:0:0:0: tag#0 CDB: opcode=0x1a 1a 00 3f 00 04 00
[ 35.879754] scsi host0: uas_eh_device_reset_handler start
[ 35.880374] xhci-hcd xhci-hcd.1.auto: ERROR Transfer event for unknown strea6
[ 35.881295] xhci-hcd xhci-hcd.1.auto: @00000000f7116cc0 00000000 00000000 1b1
[ 35.960011] usb 8-1.1: reset SuperSpeed Gen 1 USB device number 3 using xhcid
[ 35.981852] scsi host0: uas_eh_device_reset_handler success
[ 35.991856] sd 0:0:0:0: [sda] Write Protect is off
[ 35.992596] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doeA
[ 35.993685] xhci-hcd xhci-hcd.1.auto: ERROR Transfer event for unknown strea2
[ 35.994604] xhci-hcd xhci-hcd.1.auto: @00000000f7116000 00000000 00000000 1b0
[ 36.000045] sda: sda1 sda2 sda3 sda4 sda5 sda6 sda7
[ 36.003398] sd 0:0:0:0: [sda] Attached SCSI disk
Gave up waiting for root file system device. Common problems:

• Boot args (cat /proc/cmdline)
  • Check rootdelay= (did the system wait long enough?)
• Missing modules (cat /proc/modules; ls /dev)
  ALERT! LABEL=linux-root does not exist. Dropping to a shell!
  Rebooting automatically due to panic= boot argument

Kamil, please fix this error ;)

[bullet64]

And some logfiles

https://pastebin.com/R3q5ix41
https://pastebin.com/F6WswaDf

https://forum.frank-mankel.org/topic/291/rockpro64-usb3-probleme

[XDA-Bam]

I have now attached the SSD via an USB 3 compatible Y-cable with a a seperate power supply. This does not resolve the issue for me. The system still hangs 3 out of 4 times when booting, despite the external power supply for the SSD.

[bullet64]

Today i have flashed the u-boot to spi and boot from an ssd with success.

U-Boot 2017.09-rockchip-ayufan-1035-gd646df03ac (Oct 26 2018 - 08:36:24 +0000)

rock64@rockpro64:~$ uname -a Linux rockpro64 4.4.154-1124-rockchip-ayufan-ged3ce4d15ec1 #1 SMP Mon Oct 22 20:59:41 UTC 2018 aarch64 aarch64 aarch64 GNU/Linux

Bootlog https://pastebin.com/asLuPk3G

Can someone confirm?

[karlskewes]

Can you please try boot multiple times @bullet64 ?
Including after hard power cycle.
Is this a new SPI flash script?

[bullet64]

sudo shutdown now

After this i pushed the button 'Power' and it works. Two times with success!

sudo reboot now

Two times with success!

hard power cycle

Two times with success!

I am using this image -> https://github.com/ayufan-rock64/linux-u-boot/releases/download/2017.09-rockchip-ayufan-1035-gd646df03ac/u-boot-flash-spi-rockpro64.img.xz

[bullet64]

I think it's a problem with the usb3 connector on the board. I will do some more tests tomorrow.

[bullet64]

If I plug in the plug completely the device will not detected. If I do not plug in the plug completely the device will detected. And all is fine.

[bullet64]

Problem. When i can get ssd to work on usb3 port i have only usb2 transfer rate.
rock64@rockpro64:~$ sudo dd if=/dev/zero of=sd.img bs=1M count=4096 conv=fdatasync 4096+0 records in 4096+0 records out 4294967296 bytes (4.3 GB, 4.0 GiB) copied, 130.382 s, 32.9 MB/s

I give up....for the moment :)

[TrashCanMan]

I have probably the same issue than @bullet64 , rock64+jms567(pine64)+hdd-wd, both rock64 and jms adapter powered, about half of the time it wont boot (neither from complete power off nor from reboot), if i place a usb3 hub in the middle the device boots every time (no matter if i power the hub or not) (altho i get inconsistent speed in relation to having the hdd plugged directly, probably related to the extra circuitry in the middle or the bad quality of the noname hub, slower than directly plugged but usb3 speed)

I have spi flashed on the board and no emmc nor sdcard, and when the device dont boot the card powers the green led, then the red led blinks, then nothing else, when it boots it does the same but it starts to blink activity led on the jms567...

When i manage to boot the device from the hdd after a few attempts i have no problems at all, proper usb3 speed, no hang ups, no weird slow downs, no errors that i can see off, totally normal behavior, even under heavy load, i needed to transfer some heavy stuff to the disk and it worked non stop for 4 hours and no issue at all...

Im going to use it with the hub for the moment but i would prefer to destiny said hub for other tasks and use the drive plugged directly as intended...

I dont have a serial cable atm, maybe ill buy one in a few days and test again...

For the SPI i used this method and for the OS im using latest OMV arm64 from here burned with etcher and booted once, then shrink the partition with gparted to make a small partition for the OS and the rest for data...but im 99% sure this is not an OS problem since when it fails the red light on the jms567 never blinks at all, not even once...

[TrashCanMan]

BTW should i start a new issue since @bullet64 have a rockpro64 and i have a rock64? (and refer the issue with this one i guess)

[henricazottes]

@bullet64 did you get back to it recently? :)

[bullet64]

@henricazottes No, same error with rc14 and last u-boot.

[XDA-Bam]

I recently updated to U-Boot revision 1063 and have not encountered the problem anymore since then on my Rock64. Updated to the most recent 1065 five days ago and just now tested it again - three restarts in a row without hiccups. Booting fine, directly from a USB3-attached SSD (no SD card, no EMMC).

@ayufan At first glance, the fix on the Rock64 might be related to commits 135bc82 and 53c9252. This may be worth looking into to fix it on the RockPro64.

[KurtStam]

@XDA-Bam cool - I see the exact same issue on my RockPro64. Hopefully @ayufan can looking into those commits, I'm standing by to test it out.