Forcing u-boot to detect USB3 storage

[jandastroy]

So I've still been having some intermittent boot issues with my USB3 SATA drive.  Every now and then u-boot randomly gives me this result during the usb startup process:

Code:

Hit any key to stop autoboot:  0
resetting USB...
USB0:   USB EHCI 1.00
USB1:   USB OHCI 1.0
USB2:   Core Release: 3.10a
USB3:   Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.10
scanning bus 0 for devices... 1 USB Device(s) found
scanning bus 1 for devices... 1 USB Device(s) found
scanning bus 2 for devices... 1 USB Device(s) found
scanning bus 3 for devices... cannot reset port 1!?
1 USB Device(s) found
      scanning usb for storage devices... 0 Storage Device(s) found

Usually calling reset a few times fixes the issue, which is fine if I'm at home but when this happens remotely I can't do anything about it.  Until now!

I've been playing with the u-boot environment a bit and decided to try a custom bootcmd to keep trying the usb until it magically just works.  Doing this bypasses the default distro_bootcmd which calls into the sd, mmc, usb, and PXE boot options, so if you use any of these alternate boot options you may not want to do this.  I'm only interested in the usb boot device, so this setup just repeats the usb boot attempt until it succeeds or the sun burns out.

If you're having intermittent problems with your usb bootup and want to try this, you can type the following in at your u-boot console:

Code:

env set bootcmd 'itest 0 == 1; while itest $? != 0; do run usb_bootretry; done'
env set usb_bootretry 'setenv devnum 0; usb reset; if usb dev ${devnum}; then setenv devtype usb; run scan_dev_for_boot_part; fi'
env save

It's not a perfect solution, but it hasn't failed me yet so far.  It seems to get the storage device properly on the 2nd attempt every time (unless the 1st attempt works of course), but I've only been running this for a little bit.  I think this problem stems from the usb controller being in a bugged state which is why the forced retry manages to get it to start properly by resetting the adapter into a valid state.

In case you try this but want to restore the system default boot sequence, just type the following at the u-boot console:

Code:

env set bootcmd 'run distro_bootcmd'
env save

[SirRyanTheGeek]

If you're having intermittent problems with your usb bootup and want to try this, you can type the following in at your u-boot console:

Code:

env set bootcmd 'itest 0 == 1; while itest $? != 0; do run usb_bootretry; done'
env set usb_bootretry 'setenv devnum 0; usb reset; if usb dev ${devnum}; then setenv devtype usb; run scan_dev_for_boot_part; fi'
env save

Please pardon my completely ignorant question - but how to does one access the "u-boot console"? I am having the exact same problem here - I want very badly to just boot direct from the SSD attached to the USB 3.0 port and have yet to find a reliable way to do this. It only comes up about 1 out of every 7 to 10 tries of flipping the power on and off and it's getting ridiculous.

I'd even settle for the easy way I handle this on the Pi - just a small microSD card with "bootcode.bin" and an empty file called "TIMEOUT" where when the pi boots, it waits like 20 seconds before it tries to find an image to boot - which is plenty of time. It works 100% of the time on the Pi - but for the life of me I cannot at all get a consistent reboot out of the Rock64 when trying to use an SSD. 

Any ideas you have I would be eternally grateful!

[t4_4t]

> but how to does one access the "u-boot console"?

Access is via "uart".
Using this method, you get the output as shown in the #1 post above, and you can control it.

For example, access from other PCs using the following items.
 https://www.pine64.org/?product=padi-serial-console
The "u-boot" currently released for "rock64" does not provide any other way to control "u-boot".

The "boot-method" depends on the distribution (eg Ayufan/Armbian etc).
So you should clearly indicate which image you are considering using.

Otherwise, you will not get a useful response for you.

[SirRyanTheGeek]

> but how to does one access the "u-boot console"?

Access is via "uart".
Using this method, you get the output as shown in the #1 post above, and you can control it.

For example, access from other PCs using the following items.
 https://www.pine64.org/?product=padi-serial-console
The "u-boot" currently released for "rock64" does not provide any other way to control "u-boot".

The "boot-method" depends on the distribution (eg Ayufan/Armbian etc).
So you should clearly indicate which image you are considering using.

Otherwise, you will not get a useful response for you.

Well darn. Don't have one of those little things :-(

So far I was settling on Ayufan's Bionic release.

Is there a way like on the Raspberry Pi where I can put something like the bootloader "bootcode.bin" and an empty file called "TIMEOUT" onto a microSD which tells the Pi to hang tight for about 20 seconds to let things "spin up" that may be attached, and THEN boot? I do this on the Pi and it works 100% of the time. Sure it wastes a microSD, but having it reliably boot is worth it.

I flashed the SPI so it will do a USB boot - but sadly that method is inadequate when it doesn't allow for time for any attached bootable devices to always be discovered. Seems like it somewhat defeats the purpose of allowing to boot from USB - which is why you needed to do your workaround it seems.

[t4_4t]

> but sadly that method is inadequate ...
> Seems like it somewhat defeats ...

I think so, too.

It is a matter of perfection of "u-boot" itself.
It has the disadvantage of failing to detect "usb-device" or taking time to detect.
Booting from "MicroSD" and mounting "usb-device" on the "root-system" is more stable and faster.

For Ayufan's Bionic, write "bionic-minimal-xxx.img" images to "MicroSD".
Then, edit the following file and change it to mount "usb-device" on the "root-system".
/boot/extlinux/extlinux.conf
The above file is a general text file, so I think it can be understood if you look inside.

It is different from "Raspberry Pi".
Therefore, the following items have no meaning.
> Boot loaders Empty files named "bootcode.bin" and "TIMEOUT" ...

[SirRyanTheGeek]

For Ayufan's Bionic, write "bionic-minimal-xxx.img" images to "MicroSD".
Then, edit the following file and change it to mount "usb-device" on the "root-system".
/boot/extlinux/extlinux.conf
The above file is a general text file, so I think it can be understood if you look inside.

That's where I was heading, too. I'm wondering that when I list out my block devices, do I specify /dev/sda or some other label?

The file has the following in it:

Code:

root@rock64:/var/log# cat /boot/extlinux/extlinux.conf
timeout 10
menu title select kernel

label kernel-4.4.167-1163-rockchip-ayufan-g3d2c5b33817a
   kernel /boot/vmlinuz-4.4.167-1163-rockchip-ayufan-g3d2c5b33817a
   initrd /boot/initrd.img-4.4.167-1163-rockchip-ayufan-g3d2c5b33817a
   devicetreedir /boot/dtbs/4.4.167-1163-rockchip-ayufan-g3d2c5b33817a
   append rw panic=10 init=/sbin/init coherent_pool=1M ethaddr=${ethaddr} eth1addr=${eth1addr} serial=${serial#} cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory swapaccount=1 root=LABEL=linux-root rootwait rootfstype=ext4

label kernel-4.4.167-1163-rockchip-ayufan-g3d2c5b33817a-memtest
   kernel /boot/vmlinuz-4.4.167-1163-rockchip-ayufan-g3d2c5b33817a
   initrd /boot/initrd.img-4.4.167-1163-rockchip-ayufan-g3d2c5b33817a
   devicetreedir /boot/dtbs/4.4.167-1163-rockchip-ayufan-g3d2c5b33817a
   append rw panic=10 init=/sbin/init coherent_pool=1M ethaddr=${ethaddr} eth1addr=${eth1addr} serial=${serial#} cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory swapaccount=1 root=LABEL=linux-root rootwait rootfstype=ext4 memtest

 My block device list shows:

Code:

root@rock64:/var/log# lsblk -o NAME,LABEL
NAME        LABEL
sda
|-sda1
|-sda2
|-sda3
|-sda4
|-sda5
|-sda6      boot
`-sda7      linux-root
mtdblock0
mmcblk1
|-mmcblk1p1
|-mmcblk1p2
|-mmcblk1p3
|-mmcblk1p4
|-mmcblk1p5
|-mmcblk1p6 boot
`-mmcblk1p7 linux-root

So replacing "root=LABEL=linux-root" with "root=/dev/sda" you think might do the trick? Hopefully increasing the timeout to 200 instead of 10 will allow it enough time (and that it honors that value when no monitor is attached).

I'll give that a shot - thanks!

---

Nope. Didn't work that way. In fact, after the delay the indicator lights winked out on the board! lol!

Hmmm. There's gotta be a way to do this...

[t4_4t]

> sda7:               linux-root
> mmcblk1p7:    linux-root
That is because the labels are duplicated.

----
If you change the label of sda7, it works properly.

Eg) sda7: linux-root-sd

And then change the following.
root=LABEL=linux-root  ->  root=LABEL=linux-root-sd

Another way is to change the root=/dev/sda7.
However, if you connect multiple "usb-device" in this method, the device file name may change.
Therefore, It is better to specify by LABEL or UUID or PARTUUID.

In this way,
you can reliably mount the specified device regardless of the increase or decrease in the number of "usb-device" connections.

[SirRyanTheGeek]

Okay!

Changing it to use /dev/sda7 to match the same ext4 root filesystem worked like a champ. Now the filesystem looks like:

Code:

rock64@rock64:~$ df
Filesystem     1K-blocks    Used Available Use% Mounted on
udev             2038168       0   2038168   0% /dev
tmpfs             408344     436    407908   1% /run
/dev/sda7      230596488 1278064 219910820   1% /
tmpfs            2041720       0   2041720   0% /dev/shm
tmpfs               5120       4      5116   1% /run/lock
tmpfs            2041720       0   2041720   0% /sys/fs/cgroup
/dev/mmcblk1p6    114446      10    114436   1% /boot/efi
tmpfs             408344       0    408344   0% /run/user/1000

the /boot is off of the microSD card (which is fine to leave the img files there) and the rest of the setup is off of /dev/sda7. I could probably tweak it so that boot is off of /dev/sda6 but honestly that doesn't matter anymore. I just need to remember if I rebuild anything with the boot image, etc., that I make sure to update the proper img files.

For all intents and purposes, the microSD isn't being hammered now for I/O so this should be great.

Thanks!

---

> sda7:               linux-root
> mmcblk1p7:    linux-root
That is because the labels are duplicated.

----
If you change the label of sda7, it works properly.

Yep. I think I'll take the extra step and do it by UUID like you suggested in case I want to hang a backup drive off one of the USB 2.0 ports.

Thanks for your help!

[t4_4t]

Congratulations.

For example, if you to copy the image using dd=/dev/mmcblk1 of=/dev/sda etc.
Be careful because LABEL UUID PARTUUID etc. may be the same value.

And there is one more place (although it is hardly used at present ...)
There is a specification of /etc/fstab (boot: /dev/sd6), so don't forget to check and modify here too...

Good by.