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: 72)
.txt   boot.cmd.txt (Size: 2.82 KB / Downloads: 90)
  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
  How to enable ES9023-based DAC hat on Rock64? lowry 2 174 03-18-2021, 03:44 PM
Last Post: zborgerd
  1wire DS18b20 on Rock64? mypineme 3 1,118 02-10-2021, 11:21 AM
Last Post: TRS-80
  Display options for the Rock64 joey49 1 658 11-23-2020, 09:52 AM
Last Post: joey49
  Are HW design files available for ROCK64? irenek 1 1,010 09-29-2020, 05:57 PM
Last Post: tllim
  No sound from Rock64 DAC codebreaker 2 956 09-29-2020, 02:14 PM
Last Post: codebreaker
  Which Voltage and Amper to supply both Rock64 + External drive enclosure ? prog-amateur 0 923 08-21-2020, 09:16 PM
Last Post: prog-amateur
Information Rock64 RTL8188EU Wifi Adapter from Pine Store Tested Well MarkHaysHarris777 7 4,510 05-13-2020, 06:00 PM
Last Post: Leon Rembowski
  accident got 12v at my rock64 lifeform 1 1,183 04-17-2020, 09:46 AM
Last Post: fire219
  Help! Rock64 won't boot anything! trohn_javolta 3 2,018 03-09-2020, 06:03 PM
Last Post: tllim
  Power Supply and Sinks for multi-Rock64 env Davo-CC 1 2,469 01-02-2020, 02:26 PM
Last Post: dpgraham

Forum Jump:


Users browsing this thread: 1 Guest(s)