Been a long time user of the Rock 5B board and I love it! Yesterday I acquired a Rock 5 ITX board and my setup consists of 10 SATA drives, 4 connected to the SATA slots plus 6 on an NVME to SATA adapter.
Whenever I flash Ubuntu Rockchip to one of the drives the board reboots straight back to ROOBI and prompts me to install the OS again. If I remove the NVME to SATA adapter, the board boots fine.
My adapter uses the ASM1166 controller, however it is not the official Radxa adapter. I ordered one for good measure, although I am skeptical it will make any difference since it uses the same controller. I ordered it from Aliexpress so likely to take a few weeks to arrive as well.
Is there anything else I can try in the meantime? Is there a way to bypass ROOBI altogether?
Sounds like maybe the boot loader gets confused, or doesn’t enumerate enough devices to reach the bootable one. I think you should interrupt the boot and check what the boot loader is trying to do (and possibly change which device it consults).
Thanks. I’m not familiar with the process of interrupting boot and checking what it’s doing – I’m assuming the Rock 5 doesn’t have a bios I can check? Can you point me in the right direction?
You’ll need to connect a USB-UART adapter to the UART2 pins, configure it to 1500000 bps and press Ctrl-C when it starts counting down before presenting the boot menu. Then it’s u-boot, you’ll have to familiarize yourself with it (there are tons of online docs). “printenv” will show the whole config, “boot” will make it boot using default params, and there are commands around “pci”, “ext2ls” etc to do various things using various devices. But if you’re not familiar, it will take some time to discover everything I’m afraid. Usually there’s a sequence of commands that calls functions to enumerate disks and on each of them enumerate partitions to find the booting one, and that’s what will need to be modified to debug. Note that all changes are made in RAM, nothing is saved until you type “saveenv” so you will not break your boot by accident during experiments.
Yeah that sounds way too involved for something I have absolutely no knowledge of I’m afraid…
I did a bit more experimentation today and found out that:
Confirmed that ROOBI detects all 10 drives;
The system boots if I connect the boot drive to the first slot of the SATA adapter (slot 0), however once booted the 4 drives connected to the SATA slots on the board are not recognized;
The system also boots if I install the OS to the SD card, in which case all 10 drivers are recognized.
Not an ideal solution, but something that I can work with nevertheless.
Does this sound like it could be a firmware bug? I’m curious to perform the same test once the Radxa SATA adapter arrives…
Further testing is showing the SATA connections to be rather unstable, even in ROOBI.
Sometimes the OS boots with only the 4 SATAs from the board available, other times only the 6 from the adapter, other times none… and very very occasionally, all 10 are available. It’s a rather tiring game of SATA bingo every time I reboot.
You’re right, I totally forgot about that one. I faced it initially when trying early mainline kernels, but as of 6.12 it went OK, However, I might have misunderstood you, as I thought it was the extra card that’s not always detected. Sometimes some SATA links can take some time to properly train, on any system. Maybe you’re facing a race here and it would be needed to place a “rootwait=XXX” (XXX in seconds) somewhere in the kernel’s command line to wait for the device to be properly detected.
It’s great to know you fixed it! Just to clarify for future readers, when you speak about “the fix”, you mean “the patch applied to the DTS file” linked to two comments before the one you pointed to, not the hardware fix consisting in removing R29, right ?