Today I received my NVME ssd and I tried to install armbian according to this guide. My rock 5 wont boot at all. Installing it to sd card also results no boot at all. Same with debian. Can somebody please help me? The only thing that works at the moment is ubuntu server.
So radxa goofed up the power supply design?
I think I can rule out the power supply, since the system boots from sd card with the NVME drive being recognized.
Do we need any particular partition scheme?
I made single ext4 partition on my NVMe drive (using 10% of the whole size) and from the image Armbian_22.11.2_Rock-5b_jammy_legacy_5.10.110_gnome_desktop booted on sdcard, ran installer and chose nvme/spi boot option but upon reboot, device seems to be stuck with blue led.
Any idea what could be wrong?
I’m running in to this exact issue. I see you’ve solved your issue - did you use any particular partition scheme? I’ve created 1 partition on a brand new nvme ssd and am getting stuck.
Did that and still not booting from NVMe (blue led stays on forever)
Before launching install script, what parition scheme did you use for NVMe?
Currently I tried with single ext4 partition taking either part of full 2TB of disk space.
@Dann, did you ever get a hardware-accelerated chromium-browser on Armbian Jammy? I went through the same PPA steps you did (atleast it sounds like we followed same to this point), but chromium-browser remains unaccelerated. Thanks!
Finally managed to boot from NVMe only, and it happens it was a completely different issue:
power supply.
Very strange I could boot while using
SD card with Armbian,
NVMe with radxa image
but not NVMe with Armbian image !
Not sure why using another PD power supply made it work…
Now can start testing this image at last
EDIT: seems like other PD power supply is having issues as well (blue led staying on and board refusing to boot). Have to reboot several times until board finally boots (same issue I had with an android image from SD…). This device + image definitely has weird behavior with PD
You might want to try the flatpak version of Chromium, and while that doesn’t do a decent job on the webgl aquarium test, you can run youtube videos at 1080p60 without any issues when using it. With stock Chromium install, youtube videos are gawd awful.
Since I flashed the Armbian version of u-boot (rkspi_loader.img) recommended under wiki.radxa.com/Rock5/install/spi, I no longer touch my SPI Nor Flash (/dev/mtdblock0). No matter which image (Radxa, Android, Armbian) everything boots just fine whether NVMe or SD
Armbian Jammy works well for me and I followed instructions with utmost care*. Yet I don’t believe YouTube video is hardware accelerated. The video decoders show up under about:gpu, yet, Developer Tools Media still says hardware decoding NO. Also, CPU usage is significant. I don’t have dropped frames as CPU powerful enough, yet, I don’t believe it’s GPU accelerated. I don’t see any obvious debugging messages other than loads of Vulkan extension failures. (* The last step of liujianfeng1994 rockchip-multimedia PPA recommends adding --use-gl=egl chromium-browser flag. This makes overall browser experience (even mouse pointer movement) unbearably slow and I am forced to run without this flag)
Hi @Dann, I’ve had identical experiences so we must have followed the same steps. I think I will have to wait for those with the time and skill to improve the situation. I’m much obliged for your detailed run-down and it might answer questions for others besides myself.
Hi @gnattu thanks for providing from-scratch way which all the same results as Radxa’s own patched image and Armbian with panfork patches. I find Armbian Jammy Gnome with Panfork highly useable. Yet no accelarated YouTube no Vulkan no Steam so far. Radxa slightly oversold spec as lots not working due software. Even ignoring desire for mainline Linux, Mesa (Panfrost) etc. And Android I don’t know how to insert my Intel Wifi blob so stuck for me as well. Great hardware specs the board I hope can make it more useable quickly
in a termial to enable extra debug logs, and then use chromium --no-sandbox file:///usr/local/test.mp4
to play a local video file with known-to-be-supported-codec(i.e h264)?
You should get rkmpp messages from dmesg if the hardware decode is working. You may still see relatively high CPU usage but it could due to other issue.