ROCK64 bootlocks with 2 usb drives
#1
Hi, I'm veeery happy with my ROCK64 overall and I managed to setup Nextcloud manually on it. It boots via the USB3 port. (Armbian-Stretch)
I ran into a error though, which is really ruining my day:

I wanted to set another USB Flashdrive as the cloud storage, connected on a USB2 port. It all works fine when I connect it after the ROCK64 booted.
BUT the ROCK64 woun't boot at all when a second USB drive is connected. It locks before a screen output, so I think this is not an Armbian problem.
I suspect the SPI bootloader gets confused when it can't boot from the USB2 drive and it will skip booting from the USB3 port?

What I figured out yet:
Bootdrive connected on USB3 port, Storage drive connected on a USB2 port --> bootlocks before screenoutput
Bootdrive connected to a USB2 port, Storage drive connected to the USB3 port --> it boots and works perfectly fine

Question:
Can I force the bootloader to only boot from USB3 and don't check the USB2 ports?

[Image: rock64withusbsata.jpg]
  Reply
#2
(11-24-2018, 07:41 AM)Obelisk64 Wrote: Hi, I'm veeery happy with my ROCK64 overall and I managed to setup Nextcloud manually on it. It boots via the USB3 port. (Armbian-Stretch)
I ran into a error though, which is really ruining my day:

I wanted to set another USB Flashdrive as the cloud storage, connected on a USB2 port. It all works fine when I connect it after the ROCK64 booted.
BUT the ROCK64 woun't boot at all when a second USB drive is connected. It locks before a screen output, so I think this is not an Armbian problem.
I suspect the SPI bootloader gets confused when it can't boot from the USB2 drive and it will skip booting from the USB3 port?

What I figured out yet:
Bootdrive connected on USB3 port, Storage drive connected on a USB2 port --> bootlocks before screenoutput
Bootdrive connected to a USB2 port, Storage drive connected to the USB3 port --> it boots and works perfectly fine

Question:
Can I force the bootloader to only boot from USB3 and don't check the USB2 ports?

[Image: rock64withusbsata.jpg]

You need a bigger PSU, that one probably is not stable enough...

Jokes aside if you try several times it eventually boot? im using allmost the same setup but i use both drives thru a powered usb3 hub, its a workaround instead of a solution but maybe works for you too...
  Reply
#3
Quote:if you try several times it eventually boot?
It woun't boot. This bug 100% reproduceable.
I used the same drives succesfully on a raspberry pi in the same setup...
I also tried various usbdrives with various file systems, and they're all the same.

Quote:i use both drives thru a powered usb3 hub, its a workaround instead of a solution
Interesting, but I woun't buy extra hardware just because of this bug.
What are your file transfer speeds with a USB3 hub?

Quote:You need a bigger PSU, that one probably is not stable enough...
Thats just my lab supply for testing purposes. When everything is running like it should I'll switch to the regular plug pack.
  Reply
#4
Unfortunately, I cannot tell more specific, because I haven't tried this setup, but you need to look at the uboot environment. also - in the boot.cmd and armbianEnv.txt, I guess. What exactly commands are fed to it in order to get images from a USB mass storage device. Obviously, uboot isn't the bloody edge of firmwares, but there is hope, you can figure out the cause of the problem there and fix it. It looks like either uboot doesn't have the provision to precisely set up the device path to the boot medium or it does have it, but in your current set up, it's "weak" and goes nuts when finds more than one USB mass storage devices. Or rather, it tries USB2 port first. The ports are static, they should be distinguishable, not to mention they are connected to different controllers. It's pretty much the same situation as with BIOS on PCs, that easily can remember an HDD order (through what they are connected to). It's another question if uboot is able to distinguish two USB controllers though. I cannot say if it is. You can get this answer only by luck, because let's face it - their documentation is a very bad joke.
In short, show what boot.cmd contains.
  Reply
#5
(11-26-2018, 05:19 PM)z4v4l Wrote: you need to look at the uboot environment. also - in the boot.cmd and armbianEnv.txt.
you can figure out the cause of the problem there and fix it.

Puah, I've been staring at boot.cmd now for 2 hours, trying to find answers to life and death.
I'm sure that my problem could be fixed in there with one line but my linux boot procedure skills are between weak and non existant.
I could not find any hints in there, where USB ports or USB controller hubs or something like this are specified.

armbianEnv.txt doesn't contain anything interesting, but arguments for boot.cmd can be specified in there without recompiling boot.cmd.
The boot devices UUID is set in there correctly.

I also saw that a failed boot attemt (with bootdrive in USB3 with another usbdrive in USB2 slot) does not leave any log data. So the bootlock must appear VERY early in the boot procedure.

Should I contact ayufan with this bug? I got the u-boot-flash-spi-rock64.img.xz from his github...

In case anyone cares, find my armbianEnv.txt and boot.cmd attached to this post


Attached Files
.txt   armbianEnv.txt (Size: 151 bytes / Downloads: 105)
.txt   boot.cmd.txt (Size: 2.82 KB / Downloads: 127)
  Reply
#6
you need yet to look at the uboot environment. connect to UART, power the board and keep hitting esc key, or "s" key or any key (yeah, on uboot there is variance with this). then when it shows its command line, examine its variables. printenv without arguments spits them all IIRC, especially take a look at these two ${devtype} and ${devnum}. I am not a specialist in uboot/linux guts as well, but definitely your problem sits in the uboot environment.
what those variables do contain? you need to examine the command execution sequence in the uboot environment. save its printenv output, show here and analyze by yourself what that weirdo does. maybe it would be possible to force it to always try the usb3 port first. again, - there is no uboot documentation, so it's all done through this kind of guesses and tries. >_>
  Reply
#7
(11-28-2018, 06:05 PM)z4v4l Wrote: you need yet to look at the uboot environment. connect to UART, power the board and keep hitting esc key, or "s" key or any key (yeah, on uboot there is variance with this). then when it shows its command line, examine its variables.

Yeah, that'll work for diagnostics by I honestly currently don't have time for a maneuver like this. Never did anything with UART or serial terminals before.
I'll propably do this some day...
Thanks for the hint.
  Reply


Possibly Related Threads…
Thread Author Replies Views Last Post
  1wire DS18b20 on Rock64? mypineme 4 1,837 07-17-2021, 04:20 AM
Last Post: Rocky64
  Rock64 4K60P HDR Media Board Computer 64 bit MarkHaysHarris777 8 8,782 07-14-2021, 11:52 PM
Last Post: jontumontu
  Any way to tell the rock64's hardware revision? kittyland 1 345 07-01-2021, 09:42 PM
Last Post: evilbunny
  Configuring Python GPIO Pin Control Rock64 www139 3 3,730 06-22-2021, 06:57 AM
Last Post: Mrfixit2001
  POE support for the Rock64 v3 h64poe 0 352 05-30-2021, 07:40 AM
Last Post: h64poe
  3D-Printable Button Pegs for the ROCK64 Aluminium Case CounterPillow 1 547 05-21-2021, 05:44 PM
Last Post: tllim
  How to enable ES9023-based DAC hat on Rock64? lowry 2 781 03-18-2021, 03:44 PM
Last Post: zborgerd
  Display options for the Rock64 joey49 1 1,269 11-23-2020, 09:52 AM
Last Post: joey49
  Are HW design files available for ROCK64? irenek 1 1,603 09-29-2020, 05:57 PM
Last Post: tllim
  No sound from Rock64 DAC codebreaker 2 1,632 09-29-2020, 02:14 PM
Last Post: codebreaker

Forum Jump:


Users browsing this thread: 1 Guest(s)