All Activity

In the past (2019) there was no chance to use the A64-CPU Jide Remix Mini with armbian, because of a blocked -u-boot But today I found a site (from February 2025 on github) https://github.com/r4nd3l/revived_remix_mini_pc?tab=readme-ov-file which can make the Closed Jide Remix Mini to boot from SDCard with a modified u-boot There at the github page is a modified u-boot and a modified A64 armbian for the Jide Remix Mini. Jide did leave us with a closed/blocked device AT this time the 16GB emmc isnt useable, but using SDCard is a start for upcycling the Jide Remix Mini

If this fails on multiple build host environments, maybe check your network/internet connectivity. Else I don't really know what could be the cause. I use Armbian Aarch64 (RK3588s) with various tweaks ans kernels and it works fine for builds.

This suggests it is 5V only and also no USB-C PD. You should power a ROCK5 with higher voltage, then no issues, at least that is my experience and is also what you can see if you look at schematics. You can also read the end-user docs/wiki. ROCK3A, ROCK5B, NanoPi-R6C all have own step-down DC/DC converter on the board itself. The latter one for example has an 8A component for it. So it can make enough power from 20 or 15 Volt input at a perfect 5V internally for USB devices on its type-A ports, and also easily maintain its 3.3V and lower voltages for CPU etc. OrangePi is cheap, same as RaspberryPi. Those shift the powering (issues) to the end-user, meaning you need a stable enough 5V on the USB power input connector. A slight voltagedrop can lead to problems. But board itself is cheap. RPi5 requires a quite rare 5A capable 5V USB-C PD (RPI5), where the ROCK3A/5B can just be fed from any voltage between 9 and 20 Volt (see docs/wiki). If you use 5V, the on-board DC/DC step-down cannot do its work of course, so essentially bypassed. Why did you buy a ROCK5 then. Same as buying a car with combustion engine with empty fuel tank, instead put a horse in front to pull you forward from A to B. (Or get a bicycle). The (extra) horse is the 27W Pi5 PSU here, costed me 18 Euros, half the price of the ROCK3A. I put a fixed 12V on a USB-C connector, from an old card battery, that by itself is kept at about 12V by a 12V/10A generic powerbrick. Is also UPS then is no 230VAC mains. The Nanpi-R6C with latest U-Boot and latest mainline kernel does also do USB-C PD, so with a generic 45W USB-C PD PSU, is flips automatically to 15V on its USB-C input. With another 60W USB-C PD PSU it was 20V. ROCK5B should be able to do the same, but haven't tried as run 24/7 for months as home/house server.

Hi guys and Happy Christmas. I found something that could be useful. I had trouble due to fake sd card that report fake capacity. Capacity declared 64 Gb real capacity 3.7 GB. H2testw (windows) will show you the real capacity. Don't trust if it is a known brand because there are companies with machine to fake SD card. After another problem that I found is not to see the boot partition after imaging SD card. I don't know why but you must be sure that your imaging program (balena etcher o pi imager or rufus) are run in admin mode. after that in any case if it doesn't appear you have to assign a letter drive (sometimes it is not assigned) I used aomei partition manager)

Very strange, still fail when build with docker. Maybe I need to try use Ubuntu Noble. https://paste.armbian.com/ojadabewej [🐳|🔨] Processing triggers for man-db (2.12.0-4build2) ... [🐳|🔨] Processing triggers for dbus (1.14.10-4ubuntu4.1) ... [🐳|🔨] Errors were encountered while processing: [🐳|🔨] systemd-timesyncd [🐳|🔨] E: Sub-process /usr/bin/dpkg returned an error code (1) [🐳|💥] Error 1 occurred in main shell [ at /armbian/lib/functions/logging/runners.sh:15 chroot_sdcard_apt_get_install() --> lib/functions/logging/runners.sh:15 install_distribution_agnostic() --> lib/functions/rootfs/distro-agnostic.sh:327 do_with_logging() --> lib/functions/logging/section-logging.sh:81 build_rootfs_and_image() --> lib/functions/main/rootfs-image.sh:31 full_build_packages_rootfs_and_image() --> lib/functions/main/default-build.sh:36 do_with_default_build() --> lib/functions/main/default-build.sh:42 cli_standard_build_run() --> lib/functions/cli/cli-build.sh:25 armbian_cli_run_command() --> lib/functions/cli/utils-cli.sh:136 cli_entrypoint() --> lib/functions/cli/entrypoint.sh:208 main() --> ./compile.sh:50

Yes, highly recommended in order to avoid troubles. We mainly use Noble and all of our build & test automation runs on Jammy / Noble. However, when using Docker, you should have more freedom.

Thanks for you help. The host system must be Ubuntu Noble 24.04.x?

Welcome! Strange. Works here without a problem: https://paste.armbian.com/uqutokajas

clone the latest armbian/build repo, run ./compile.sh but fail. I try native or docker build, all fail.

I've used an encrypted root in my configuration. I've found earlier versions of the vendor kernel to not include dm_crypt, so I've always used the edge kernel. That one's been quite reliable with encryption. If you're using serpent encryption, that's one that's more likely missing than the others. Run this to see if serpent's missing (from your (vendor) kernel): cryptsetup benchmark If serpent is missing, it will report N/A instead of a speed for that one. If you really want to use a vendor kernel, you can build it yourself... being sure to include dm_crypt, and if necessary, a serpent encryption module.

I was rechecked that openvfd works and get its config openvfd dtbo overlay fragment (decompiled on running system) It works, driver loaded and userspace software shows me current time on LED (some segments shows wrong, i think it result of wrong chars config) tm16xx: I've tried many values for GPIO line config, GPIO_ACTIVE_LOW (1), GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN (6), GPIO_ACTIVE_HIGH (0), GPIO_ACTIVE_LOW | GPIO_OPEN_DRAIN (7). It was no result at all, driver still says that cannot init controller. Also i was tried drivers fd6551, fd655 with different GPIO lines config. No success. I was rechecked LED controller chip on board, it is really FD6551. tm16xx dtbo overlay fragment (decompiled on running system) I have no ideas what goes wrong. When i was configure openvfd device tree, pointing gpio chip as &gpio was not works. Only pointing as "0300b000.pinctrl" was successful. Maybe, its important... Maybe, some features/conflicts at controller init needs debugging

Rock 5-whatever are really picky with power supplies. They are skipping like a school girl if the power supply is not right. I have for example one relative dumb little power supply with 2 outputs and using both outputs with Orange Pis works just fine. When I used one output with the Rock 5b+ I saw many crashes. It just hard reset at various stages. After connecting it to a usb output from a powerstrip it worked just fine. Radxas devices are really really picky is what everybody needs to keep in mind.

@humanus I would argue that if you build your own image with your own u-boot that uses the vendor versions of BL31 Elf and DDR Bin plus some rootfs, you can test very quickly different kernel versions to see if latest mainline kernel 6.18 or 6.19-rc is working. U-Boot is quickly to build # extract u-boot cd u-boot-2026.01-rc5 # Get bl31 and ddr. Maybe even try newer versions of BL31 and DDR curl -LO https://raw.githubusercontent.com/rockchip-linux/rkbin/0b3e87afc2abd8dd6eb0052cd1be00de94a96637/bin/rk35/rk3528_ddr_1056MHz_v1.09.bin curl -LO https://raw.githubusercontent.com/rockchip-linux/rkbin/bf63f186b9d6ffeca758278f8cadb5d5e5dc7f86/bin/rk35/rk3528_bl31_v1.17.elf # Create the u-boot config make rock-2-rk3528_defconfig # Enable more config options like this, ONLY if really needed scripts/config --enable CONFIG_USE_PREBOOT scripts/config --set-str CONFIG_PREBOOT 'led green on; sleep 0.1; led green off' scripts/config --set-val CONFIG_LOGLEVEL '7' scripts/config --set-val CONFIG_SPL_LOGLEVEL '7' # If you enabled more than default, update the config make olddefconfig # Build u-boot make EXTRAVERSION=-MyAwesomeUboot-1 BL31=rk3528_bl31_v1.17.elf ROCKCHIP_TPL=rk3528_ddr_1056MHz_v1.09.bin # use u-boot files to flash - idbloader.img - u-boot.itb sudo dd of=/path/to/rock-2f-archlinux.img bs=512 conv=notrunc if=/path/to/idbloader.img seek=64 sudo dd of=/path/to/rock-2f-archlinux.img bs=512 conv=notrunc if=/path/to/u-boot.itb seek=16384 # or the combined file - u-boot-rockchip.bin sudo dd of=/path/to/rock-2f-archlinux.img bs=512 conv=notrunc if=/path/to/u-boot-rockchip.bin seek=64 This is just an idea to get you started and created relative quickly a base image for a boot test. If you have a process to build that quickly, flash it and try to boot. Hook up a serial console and if it boots interrupt the u-boot to get to the u-boot prompt. If you get there, you don't need to think about to much about the boot loader in the image. Because at that prompt you can test various boot options live, instead of editing something on the sdcard or to whatever medium you flashed it. Here are some thoughts and notes on how you can debug and try to boot from the u-boot prompt. # Lets assume device 1 is the SDCARD with the system on it # Check you disks (sdcard / emmc) mmc list mmc dev 1 mmc list mmc part # Maybe that will show you something like this. => mmc list sdhci@2a330000: 0 (eMMC) mmc@2a310000: 1 (SD) mmc@2a320000: 2 (SDIO) # 'dev part' will show you the partitions. # Lets assume you have 3 partitions on and part 3 is your system # Check if you can read files ls mmc 1:3 ls mmc 1:3 /boot/ # Now if you know your Linux kernel image, initrd and DTB name, you can try to boot load the files and boot # You get the PARTUUID from the 'mmc part' above load mmc 1:3 ${kernel_addr_r} /boot/Image load mmc 1:3 ${fdt_addr_r} /boot/dtbs/rockchip/rk3528-rock-2f.dtb load mmc 1:3 ${ramdisk_addr_r} /boot/initramfs-linux.img setenv bootargs 'root=PARTUUID=ab3ede6d-b4b9-4368-80a9-a029b67cca29 console=ttyS0,1500000 rootwait' booti ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r} Most important is you need to figure out what the serial console really is. If it is not ttyS0, try ttyS1 or ttyS2. The above "bootargs" at very basic. If you don't see much, try adding more. Here are some example you can add. Not all at ones! earlycon=uart8250,mmio32,0xfeb50000 console=tty1 console=ttyS2,1500000 console=both consoleblank=0 loglevel=7 panic=10 rootwait rw init=/sbin/init rootfstype=ext4 The "earlycon" parameter is also board specific. Not sure if it is valid for a Rock 2F or what the correct address would be. Again, this is not a working step by step guide but something that I would try to use for development and debugging. Once you have something working, I would think about integrating it into the Armbian config files.

Mainline 6.18 or 6.19 does only decoding accelerated, not encoding (yet) what is to great benefit of Jellyfin. Also for that transcoding, Jellyfin uses RKMPP, not V4l2. So 6.1.115 vendor kernel is what I use on the Jellyfin server (headless). For desktop RK3588, I use mainline 6.18.2 at the moment, brute force SW decoding, that works for me as content is max 1080p60 (HEVC or VP9 or H264).

Update 1. The LibreElec solution that Dante suggested works very well, if the only thing that is wanted is the video acceleration and kodi. Unfortunately, if one wanted to also add a Jellyfin server on the Nanopi R6S (which works well with video acceleration), then LibreElec is an issue because it won't allow installing that software. Nonetheless, right now, it appears to be the only option besides FriendlyElec. 2. The Armbian solution does not allow for stutterless playback of 2160 videos for some reason. Please see the logs below: https://paste.armbian.com/akudoyopas In general, I would much prefer a solution with Armbian which would allow a lot more flexibility with my setup.

Hello everybody, My Box is a oxtagon shaped t95z plus 2 mb 16 mb I try to install armbian_community_26_2 _0-trunk.100 aml-s9xx-box_noble_current_6.12.63_cinnamon_dektop.img.xz I use meson-gxm-vega-s96.dtb And u-boot-s905x-s912.dtb copy and rename as u-boot.ext It boots to ash then it stops No asking for password and user I have no clue what to do next I have entered armbian-confug but this returns a error Any tips?

@robertoj I apologize, perhaps you missed the message.

Looking at transpeed-8k618-t-allwinner-h6.dtso, you may need these flags instead of 0/1: (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN)

May worth enabling dyndbg to see debug output: dmesg -C modprobe -r tm16xx && modprobe tm16xx dyndbg dmesg

On internet i can't find any image for this tv box. Anyone have build for this?

Yes, i've tried pin flag 0 and 1 -- no effect

Today investigated, why BCM Bluetooth was not working with my image. What a rabbit hole 🙄 Also added OrangePi R2S board. Smaller brother of RV2 (I have no board but it's probably working). For the Bluetooth: everyone is obviously happy to hack the BCM firmware file instead of implementing bcm init into hciattach. The brcm_patchram_plus firmware hacking tool was added for this arch and that arch as a binary under BSP for different boards. Not very Debian-style. I grabbed the working source, compared to the one avail in Android AOSP and added it to my branch, added lib6-dev-riscv64-cross to the Docker image and now have a working image with BT. LG && HTH // Sven-Ola

Have you tried setting the pin flag to 1 as in your open vfd config? sda-gpios = <&pio 8 12 1>; /* PI12 */ scl-gpios = <&pio 8 11 1>; /* PI11 */

Thanks!! I had compiled tm16xx, attach dtb overlay, and trying to load modules. dmesg: my old dts overlay for openvfd: new dts overlay: Configs looks equals in hardware config, but driver not loading...

http://blog.armbian.com/content/images/2025/12/holiday1-1.pngFrom major kernel milestones to expanding our support for the latest ARM and RISC-V hardware, 2025 has been a year of growth and grit for Armbian. As we wrap up the final commits of the year, we’re looking back with gratitude at how far this project has come. The holiday season is our favorite time to reflect on the power of open source - where a global community comes together to make hardware work better for everyone. Thank you for being part of our story this year. Happy Holiday Hacking! Public beta: new Armbian OS image flasher. Clean, simple, open-source tool for flashing Armbian or any other disk image to your single board computer. Download for Linux / Window / MacOS Nanopi R76SThe ultimate travel router and secure hotspot Forget insecure hotel Wi-Fi. The NanoPi R76S, powered by the performance-optimized Armbian OS, is your ticket to a truly secure, high-speed mobile network. This pocket-sized device is built around the powerful Octa-core Rockchip RK3576 SoC and supports up to 16GB of LPDDR5 RAM,http://blog.armbian.com/content/images/icon/favicon-35.icoArmbian blogIgor Pecovnikhttp://blog.armbian.com/content/images/thumbnail/r67-1.jpgSponsored Post Armbian flashing toolWe’ve added a powerful new Image Flashing Tool to Armbian! You can now browse, download, and flash Armbian images directly to your device’s internal storage or boot media - no external tools required. Everything happens seamlessly inside armbian-config, making installation and re-installation faster, safer, and easier than ever.http://blog.armbian.com/content/images/icon/favicon-32.icoArmbian blogIgor Pecovnikhttp://blog.armbian.com/content/images/thumbnail/ChatGPT-Image-Dec-8--2025--11_11_38-PM.pngGithub HighlightsThis week in Armbian development saw significant progress across board support, kernel updates, and codebase improvements. Notable additions include support for the SpacemiT MusePi Pro and Friendlyelec NanoPi Zero2, alongside expanded compatibility for TI AM62x SoC boards. Multiple platforms, such as Rockchip, Meson64, and Sunxi, received kernel bumpst to newhttp://blog.armbian.com/content/images/icon/favicon-34.icoArmbian blogMichael Robinsonhttp://blog.armbian.com/content/images/thumbnail/highligts-2.pngView the full article