Armbian images are now available for Rock 5b!

Hi there,

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.

I had issue and used a fix power supply (12v5a) with barrel to usb-c adapter then all my images worked.

1 Like

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.

Mine would boot from usb-c pd power for the radxa images, but my armbian images would not negotiate pd…

Same thing happened to me. What I did is explained below.

  1. Booted from Sdcard (provided you already have special uboot for armbian installed in spi, link -> )
  2. Used Gparted to format Nvme storage to ext4 (made single partition).
  3. Downloaded the required image to sdcard from (Tried debian and ubuntu , both worked).
  4. Then finally ran
    sudo sudo xzcat ’ your compressed image path’ | dd of=’ your NVME SSD device path’ bs=1M status=progress.

#such as:
sudo xzcat rock-5b-debian-bullseye-xfce4-arm64-20220906-0626-gpt.img.xz | dd of=/dev/nvme0n1 bs=1M status=progress

4.Restart and Remove Sdcard.

Voila , it boots and works even after upgrading firmware and packages.

There are only two steps. Once you are in the console:

  • sudo armbian-install (click, click, click … )
  • saying small “thanks

Second small bug related to flashing is also in the works.

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.

The steps that helped me are:

  1. Erase spi flash with dd if=/dev/zero of=/dev/mtdblock0 bs=1M count=16
  2. Install nvme-cli and issue nvme format -s /dev/nvme0n1
  3. Create a primary partition with fdisk
  4. Formatt the created partition with mkfs.ext4
  5. Run armbian-install and select boot from SPI system on nvme, then update the spi bootloader

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!

trying to follow your steps, when issuing nvme-cli command, I get

rock-5b:~:% nvme format -s /dev/nvme0n1
Expected byte argument for ‘ses’ but got ‘/dev/nvme0n1’!

another question: did you use GPT as for partition table?

do we need doing anything particular for that or just let install script doing it is enough

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

1 Like

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.

1 Like

Thank you! That did it for me. I suspect wiping the SPI flash was the trick.

Use nvme format -s 1 /dev/nvme0n1

Explanation for the Secure Erase Settings is on

1 Like

Since I flashed the Armbian version of u-boot (rkspi_loader.img) recommended under, 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)

1 Like

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.

1 Like

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

For a minimal testing, could you try to do something like

export mpi_debug=1
export mpp_debug=1
export h264d_debug=1
echo 0x100 > /sys/module/rk_vcodec/parameters/mpp_dev_debug

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.