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.
ANT - my hobby OS for x86 and ARM.
  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: 207)
.txt   boot.cmd.txt (Size: 2.82 KB / Downloads: 243)
  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. >_>
ANT - my hobby OS for x86 and ARM.
  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
  Are HW design files available for ROCK64? irenek 3 4,534 12-11-2023, 09:31 PM
Last Post: tllim
  Rock64 is unreliable after 3 years of service - power problem? ReleaseTheGeese 0 278 11-23-2023, 05:05 AM
Last Post: ReleaseTheGeese
  Rock64 PoE compatbility with Pi4 Hatt recent Single Board Computer offering from PINE kharak 1 974 04-26-2023, 11:38 PM
Last Post: tllim
  Case for the rock64 that supports the POE hat. o1CRiMSON1o 0 576 03-21-2023, 03:48 PM
Last Post: o1CRiMSON1o
Brick Rock64 usb2.0 Power Control Floating GPIO Tutorial Files & Notes MarkHaysHarris777 6 13,042 01-15-2023, 10:36 AM
Last Post: ds00
  rock64 totally brick dakobg 2 1,648 11-07-2022, 05:45 PM
Last Post: olivercfc
  3D-Printable Button Pegs for the ROCK64 Aluminium Case CounterPillow 2 3,408 08-04-2022, 01:31 AM
Last Post: Vicky Weimann PhD
  Where can I find the ROCK64 POE HAT Zoz 2 2,498 06-08-2022, 12:44 AM
Last Post: Zoz
Smile wooden case for ROCK64 killor 13 16,174 03-04-2022, 06:56 AM
Last Post: killor
  1wire DS18b20 on Rock64? mypineme 6 6,826 09-28-2021, 03:07 PM
Last Post: TRS-80

Forum Jump:


Users browsing this thread: 1 Guest(s)