All Activity

Hi every one, Do we have a fix for bluetooth?

Try to experiment with this value: https://github.com/armbian/build/blob/main/patch/kernel/archive/rockchip64-6.6/board-rockpro64-0001-Add-pcie-bus-scan-delay.patch As this is pulled to DT, you only need to recompile DT - on board.

I don't think there are pre-built images with both ha and de by default. You can try to build your own by adding this extensions to your own userpatches and enable it: https://github.com/armbian/os/blob/main/userpatches/extensions/ha.sh

Is it just modifying the dtb? I was reading and I understand that means decompiling to dts and then recompiling but what edits would I have to do to enable eMMC?

@Error1429 If you were to submit a well thought out PR along with the necessary doc and website updates, I'm sure this would be accepted and incorporated. But I think the feedback thus far as that this isn't something of high enough priority to ever being incorporated with Armbian's very limited resources.

I think having a direct Composite output could be used with for example car monitors or other things, I don't see why it shouldn't be supported out of the box and it might work on all H3-based boards, some of which have a dedicated pin inside the headphone jack. For example Orange Pi PC. Also, composite video is supported from the start on a Raspberry Pi Zero, which also requires soldering to get it to work. I would say that more people are able to solder one pin rather then search the whole internet how to compile the whole kernel with patches. The video pin on the Orange Pi One isn't really that hard to access as it is on the bottom of the board.

IMHO this is a waste of money. In a device with NVME support, the advantages of an NVME SSD far outweigh those of an eMMC. The proprietary module interface also makes it difficult to use in other devices. And as a boot device for the firmware, it also offers no significant advantages over a microSD card. In any case, I would prefer a microSD card as a boot device, simply because of the easier handling when, for example, experimenting with the firmware. Only when everything works perfectly can one think about using an eMMC, but only if it is already permanently built into the device and the microSD card slot is to be kept free for other tasks. Only as long as there is no valid firmware signature in the SPI flash. Otherwise, firmware components will be loaded from there, and they may be able to load subsequent components (U-Boot) from other devices, but compatibility must be ensured. To avoid this, one must clean the SPI flash or store their own firmware in the SPI flash. However, since there is no way to fully test one's own firmware for functionality in advance, one may find oneself in a situation that requires a MASK-ROM recovery procedure. I prefer to trust the official documentation.

@laibsch Thanks for the advise, also posted a link to here to the radxa forum, where another user is also having the same issue. Will keep this updated if anything comes around at their end If anybody else got an idea or needs more info/tests done by me, feel free to ask, i can submit serial console logs.

Hello, thank you for these clear instructions. Could you tell me where could I find the zip file?, it seems the link if broken. Thank you

@eselarm I agree with you, it's a fabulous device. And like you, hours after the post, I realized that I only need a VM host. I was thinking about the M6, but why get stuck with Windows ARM when Debian and Android also work on Intel? These bonsai devices are really appealing, but for now I've returned it to Amazon. I bought it as a gateway-media server, to have priority on the LAN and lighten Android TV, but I realized that with MediaTek there is a huge gap in network management, so I put it on the LAN, and Debian in VNC was running strong, I wanted to speed it up with Armbian. Apart from the fact that they call their community “third parties,” it still seems like a good idea to me. I could install the generic Arm64-xfce with mesa-vpu... engineering-wise, it's incredible in 6 square centimeters, but an i7 tower is more convenient for VMs.

Is there an Armbian image with home assistant that isn't minimalistic? or Is there a way to install HA on a more robust desktop armbian 25.2 image for the Orange Pi 5 Plus? I feel the orange pi 5 is robust enough to handle HA under a desktop Armbian environment than other SBCs.

@ABhomeuser the board page is a bit out of date https://www.armbian.com/orange-pi-zero-3/ Debian 12 (Bookworm) Minimal / IOT SHA ASC 241.1 MB Debian 12 (Bookworm) Minimal / IOT SHA ASC 230.3 MB @Igor ^ how do we update that on the boards page? are actually the same file. proof: download the sha file for each of them and look at the content, you can see that both the filename and hash is identical in both sha texts. this means that both files are in fact identical and actually the same size, despite the incorrect file size indication on the front page. in fact that is currently linked to this release on github https://github.com/armbian/community/releases/tag/25.8.0-trunk.375 ^ this is released last week there are in fact 'earlier' releases, I'm running an image from this release https://github.com/armbian/community/releases/tag/25.8.0-trunk.309 I'd suggest going with the 'latest and greatest' (trunk 375) (which is that on the boards page currently) and if there are issues, then try that a little earlier e.g. in the latter link (trunk 309). armbian community images are rolling releases, they are 'fast moving' and perhaps come back in a few weeks, and it could be another trunk release number. but simply take an image 'as of now' and normally it 'just works' e.g. from the boards page.

Hi i want to know if it’s possible to connect a raxda rock 5B with armbian on a touch screen Joy-it LCD10 V2 Module écran tactile 25.7 cm (10.1 pouces) 1280 x 800 Pixel by usb and hdmi ?

Hurray Wayland is fixed! Thank you very much! You have no idea how important this is! I for example use this setup on a permanent basis: Web surfing, Text editors, etc. This is my main system. And you know how upset I was when the Wayland subsystem broke.

Hi everyone! I have v25.8 rolling for radxa cubie a5e running Armbian Linux 6.14.0-rc1-dev-sun55iw3 runnig and it has only ttyS0 serial device. Due to device schematics it should be able to provide serail interfaces with RTS/CTS support UART4-7. Was anyone able to activate this devices? As I understand, I need an overlay .dtbo files. But those cannot be found anywhere in /boot. Also I can compile those overlays, but I need the correct .dts files.

thanks for the answer. i wonna boot from the emmc, so i have bought an little emmc module, so there should no hassle with the MASK-ROM, right ? just trying to build mainline u-boot ragarding this: https://uthings.uniud.it/building-mainline-u-boot-and-linux-kernel-for-orange-pi-boards but, of course, getting errors 😞 Image 'simple-bin' is missing external blobs and is non-functional: rockchip-tpl atf-bl31 /binman/simple-bin/mkimage/rockchip-tpl (rockchip-tpl): An external TPL is required to initialize DRAM. Get the external TPL binary and build with ROCKCHIP_TPL=/path/to/ddr.bin. One possible source for the external TPL binary is https://github.com/rockchip-linux/rkbin. /binman/simple-bin/fit/images/@atf-SEQ/atf-bl31 (atf-bl31): See the documentation for your board. You may need to build ARM Trusted Firmware and build with BL31=/path/to/bl31.bin Image 'simple-bin' has faked external blobs and is non-functional: rockchip-tpl Image 'simple-bin' is missing optional external blobs but is still functional: tee-os /binman/simple-bin/fit/images/@tee-SEQ/tee-os (tee-os): See the documentation for your board. You may need to build Open Portable Trusted Execution Environment (OP-TEE) and build with TEE=/path/to/tee.bin Image 'simple-bin-spi' is missing external blobs and is non-functional: rockchip-tpl atf-bl31 /binman/simple-bin-spi/mkimage/rockchip-tpl (rockchip-tpl): An external TPL is required to initialize DRAM. Get the external TPL binary and build with ROCKCHIP_TPL=/path/to/ddr.bin. One possible source for the external TPL binary is https://github.com/rockchip-linux/rkbin. /binman/simple-bin-spi/fit/images/@atf-SEQ/atf-bl31 (atf-bl31): See the documentation for your board. You may need to build ARM Trusted Firmware and build with BL31=/path/to/bl31.bin Image 'simple-bin-spi' has faked external blobs and is non-functional: rockchip-tpl Image 'simple-bin-spi' is missing optional external blobs but is still functional: tee-os /binman/simple-bin-spi/fit/images/@tee-SEQ/tee-os (tee-os): See the documentation for your board. You may need to build Open Portable Trusted Execution Environment (OP-TEE) and build with TEE=/path/to/tee.bin Some images are invalid so getting the blobs from the rokchip repos : -rw-rw-r-- 1 baumgart baumgart 430880 Jul 23 10:58 rk3588_bl31_v1.48.elf -rw-rw-r-- 1 baumgart baumgart 473512 Jul 23 10:58 rk3588_bl32_v1.19.bin -rw-rw-r-- 1 baumgart baumgart 75320 Jul 23 10:58 rk3588_ddr_lp4_2112MHz_lp5_2400MHz_v1.18.bin -rw-rw-r-- 1 baumgart baumgart 71600 Jul 23 10:58 rk3588_ddr_lp4_2112MHz_lp5_2736MHz_eyescan_v1.11.bin -rw-rw-r-- 1 baumgart baumgart 6464 Jul 23 10:58 rk3588_pcie_v2.20.bin -rw-rw-r-- 1 baumgart baumgart 512 Jul 23 10:58 rk3588_ramboot_null0.bin -rw-rw-r-- 1 baumgart baumgart 512 Jul 23 10:58 rk3588_ramboot_null1.bin -rw-rw-r-- 1 baumgart baumgart 49276 Jul 23 10:58 rk3588_ramboot_v1.06.bin -rw-rw-r-- 1 baumgart baumgart 239010 Jul 23 10:58 rk3588_spl_v1.13.bin -rw-rw-r-- 1 baumgart baumgart 90268 Jul 23 10:58 rk3588_usbplug_v1.11.bin so, ROCKCHIP_TPL should be the rk3588_ddr_lp4_2112MHz_lp5_2400MHz_v1.18.bin but BL31 ? rk3588_bl31_v1.48.elf or rk3588_bl32_v1.19.bin where do i get an OP-TEE bin ?

It all depends on what version or variant of OS you are using. I have a R6C and have done many fixes and workarounds for various OSses/distros to the point that I just maybe take what generic upstream kernel does. I anyhow change/fake MAC addresses as I use bridges and also VLANs. Is in Armbian Bookworm and Opensuse Tumbleweed. Ubuntu based has and extra netplan layer that is even more a PITA as it keeps .nmconnections file also in another place (generated) then /etc/NetworkManager/system-connections/ Recently a change in scripting has been done so that name 'wan' is/or has been changed into 'wan1', so at least this does not match what is printed on the metalcase. At least that is what I remember from a quick check on github; See what is in your udev rules scripts yourself. https://github.com/armbian/build/blob/main/config/boards/nanopi-r6s.conf

it all depends on what your plan is what the device should do; I have a R6C for about 18 months now and bought it as an alternative/better more integrated alternative for existing RPi4 (and also RPi5 that still has no M.2 socket). I see many people on for example RPi forum who want to create some router thing, so they buy HATs and USB stuff for an RPi, but this NanoPi series has even WRT preinstalled. I removed it as I wanted generic server box (virtual machines host mainly). I do not really need the 2x RJ45 currenlty, but the metal case is great. Is simple passive cooling and insect/animal proof. It is mainly bootloader and kernel (and DTB/overlays) that matter. The userspace can be taken from elsewhere if you know how to. I currently use the R6C as desktop as well in another cooler room (summer hot here). EDK2-UEFI v1.1 bootloader, Armbian edge 6.16-rc3 kernel, Opensuse Tumbleweed for Btrfs rootfs to drive a DVI monitor KDE plasma 6.4.x. It means various Rockchips HW blocks do not work like NPU and video codecs HW accel block, but that is a choice. If you need those, use vendor kernel and see what exctly you need/want. The 2x RJ45 might be a chalenge, see maybe also:

I also needed a desktop on my Orange Pi Zero 2. I installed an "Armbian 25.5.1 Bookworm Minimal / IOT", then installed an XFCE desktop using some short guide I found on the Internet: sudo apt install lightdm xfce4 xfce4-goodies xorg After a reboot, my desktop started without any additional configurations. It's so good that now I have a new system with a desktop on my old hardware, which doesn't provide fresh OS images anymore.

That is a lot of work to get video for TVs that today have HDMI anyway. The audio out for an orangepione would also require audio amplifiers. Not many people have the skills to solder to the tiny pads on the orangepione and could easily destroy the board. HDMI for the orangepione works very well for both audio and video. That said, the orangepione with 512KB memory is under powered to run a desktop environment.

Alright, was described a bit weird so I assumed you were talking about some 3rd party image. I cannot tell what's the difference or if they work better than ours since I don't use or deal with those. Best you just give all of them a try. Bullseye is Debian old-stable and will soon become old-old-stable. So if you don't want to deal with multiple major upgrades, if possible at all, I'd recommend to start with Bookworm or even Trixie (which I assume will not introduce major breakage until finally released in August since most packages are frozen already).

I suggest - if you want to continue with this approach - to add this as an extensions since having the necessary patches built-in for a board that needs hw modifications makes no sense. Examples: https://github.com/armbian/build/tree/main/extensions

Hello there! I was looking at the new images from May 28th and noticed that for the minimal/IOT section there was two Debian Bookworm images with the exact same name. They appear to have a different sizes (230 and 241 mb) but no explanation is given for what exactly is different between the two. Does anyone here know what the difference between these two images are?

Good news! I have finally built a new image (v0.7). It uses the v2025.07 u-boot from the 'orangepi5-pro-uboot' branch, and now the eMMC is working correctly. (Thanks to @salas for testing!)

I also tried sudo dd if=official_rock5t_image.img of=working_idbloader.img bs=512 skip=64 count=8000 sudo dd if=official_rock5t_image.img of=working_u-boot.itb bs=512 skip=16384 count=8000 sudo dd if=working_idbloader.img of=armbian_image.img bs=512 seek=64 conv=notrunc sudo dd if=working_u-boot.itb of=armbian_image.img bs=512 seek=16384 conv=notrunc then burn the img into the SD card, also be able to boot. I got the official image from https://github.com/radxa-build/rock-5t/releases but there's another issue, the hardware acceleration does NOT work in armbian, Mali-G610 is not in use