All Activity

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

@Werner Sorry to open it again, but that the download in the middle of the page https://www.armbian.com/nanopi-r5c/ is third party, I realized it now by re-reading in the middle of the page. Can I ask you for an opinion? Given the type of device (one of many Pi), I would have a better ratio (hw-performance / sw-conflict), running: 1) this fork; 2) the official; 3) debian 12. Compared to Debian 11 desktop factory iso, this fork increase very few performances. Does it make sense, in your opinion, that I improve with Armbian Stable? Thanks anyway! PS: also for the previous post, I re-read in the middle of the page and you say to give the archive.xz to usbimager. But considering that people generally flash iso's (windows, linux and even Nano Pi factories), for Pi's newer it is not obvious, it should be reiterated in parentheses.

I Have an A96X with rockchip RK3228 and i tried booting armbian on it, but I got no display on HDMI. I connected a serial adapter to it and here is the information it displays when trying to boot: ▒▒▒▒DDR Version V1.05 20160805_dbg In 300MHz DDR3 Bus Width=32 Col=10 Bank=8 Row=15 CS=1 Die Bus-Width=16 Size=1024MB mach:2 OUT Boot1 Release Time: 2016-03-15, version: 2.31 ChipType = c 275 No.1 FLASH ID:2c 64 44 4b a9 0 ECC:60 SdmmcInit=0 0 BootCapSize=0 UserCapSize=76f5000 FwPartOffset=2000 , 0 StorageInit ok = 1520008 SecureMode : SBOOT_MODE_NS hdr 0x0:ff a1 0 0 1b 0 0 0 f0 f2 2e 68 f0 f2 2e 68 hdr 0x0:a4 81 0 0 4e 23 0 0 f0 f2 2e 68 f0 f2 2e 68 hdr 0x0:ff a1 0 0 3 0 0 0 f4 f2 2e 68 f4 f2 2e 68 hdr 0x0:a4 81 0 0 44 0 0 0 f4 f2 2e 68 f4 f2 2e 68 hdr 0x0:0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 hdr 0x0:0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 hdr 0x0:0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 hdr 0x0:0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 SecureMode : SBOOT_MODE_NS Loder code check ok! theLoader 0x60000000, loadaddr: 0x2000 Loder code check ok! theLoader 0x68400000, loadaddr: 0x4000 INF TEE-CORE:init_primary_helper:319: Initializing (1.0.1-63-g23e91df-dev #16 Tu e Mar 7 10:07:15 UTC 2017 arm) INF TEE-CORE:init_primary_helper:320: Release version: 1.8 INF TEE-CORE:init_teecore:79: teecore inits done U-Boot 2017.02-RK322X-06-02276-ga7c7ca8-dirty (May 19 2017 - 11:16:15) CPU: rk322x cpu version = 3 CPU's clock information: arm pll = 600000000HZ periph pll = 600000000HZ ddr pll = 600000000HZ codec pll = 500000000HZ Board: Rockchip platform Board Uboot as second level loader DRAM: Found dram banks: 1 Adding bank:0000000060000000(0000000040000000) Reserve memory for trust os. dram reserve bank: base = 0x68400000, size = 0x00100000 128 MiB GIC CPU mask = 0x00000001 rk dma pl330 version: 1.4 remotectl v0.1 pwm freq=0x11e1a3 pwm_freq_nstime=0x355 SdmmcInit = 0 0 SDCard Update. storage init OK! Using default environment Writing env to storage... done GetParam W: Invalid Parameter's tag (0x00000000)! Invalid parameter No pmic detect. SecureBootEn = 0, SecureBootLock = 0 #Boot ver: 0000-00-00#0.00 empty serial no. normal boot. no fuel gauge found no fuel gauge found read logo on state from dts [0] no fuel gauge found 'recovery' does not seem to be a partition nor an address Unable to boot:recovery try to start backup 'backup' does not seem to be a partition nor an address Unable to boot:backup try to start rockusb Can anybody point me to the right direction? I'd really like to turn this piece of junk into something useful 😄 Any help will be greatly appreciated! Thank you.

Hello, I found this guide: https://github.com/robertojguerra/orangepi-zero-full-setup/blob/main/README2.md I followed the steps and built an Armbian image with current 6.12 kernel and now TV OUT (CVBS, Composite Video), after soldering a cable to the video pin on the board, is working on my Orange Pi One with an Allwinner H3 CPU (the patches might work for other H3/H2+ boards). I would like to get that functionality incorporated into Armbian.

You forgot to mention a very important caveat, in that all filesystems on that device sda should be unmounted when you dd (BTW, pv is cooler than dd for this). That means, you have to boot off a different device. "sudo dd bs=4M if=/dev/sda | xz -v armbian_odroidc4_11_01_2025.img.xz" gets you the desired compression in one go. | is called a pipe.

so, you are good now?

Hello and thank you for your problem report. You are absolutely spot on, no worries! Your board is community maintained status. I would advise you to try and contact Chris, the listed maintainer of this board and see if you guys can pinpoint the root cause of the problem and provide a fix we can incorporate via a PR.

not sure, but sounds like a boot order issue? @meco, I believe you are the maintainer for this board, aren't you?

Unfortunately an added challenge of the older SOC (A10, A13 & A20) generation is a limitation of the video engine which can only access the first 256MB of DRAM. I have tested this and found that the system becomes unresponsive as soon as we attempt media playback which confirms this is true. I dont yet know how it works under the hood but probably a similiar mechanism to how the kernel parses the dts in order to know what modules to load during the boot process. Allocation and ranges are set within the memory reserved node. reserved-memory { #address-cells = <1>; #size-cells = <1>; ranges; /* Address must be kept in the lower 256 MiBs of DRAM for VE. */ default-pool { compatible = "shared-dma-pool"; size = <0x6000000>; alloc-ranges = <0x40000000 0x10000000>; reusable; linux,cma-default; }; }; I have also tried increasing via overlay but it seems anything larger than 96MB gets disassociated from the dma pool. The first address that gets allocated is 0x4a000000. Trying via the extraargs method to specify a lower start address fails. Looks like the display buffers take a chunk out of CMA as well. Monitor disconnected: ryan@pcduino2-2:~$ cat /proc/meminfo | grep Cma CmaTotal: 98304 kB CmaFree: 98008 kB Monitor connected: CmaTotal: 98304 kB CmaFree: 89780 kB If I attempt to fast forward, playback falls back to software decoding and I get these errors in the log: [ 596.444060] cma: __cma_alloc: reserved: alloc failed, req-size: 1024 pages, ret: -16 [ 596.444103] cma: number of available pages: [ 596.444110] cma: range 0: 3@109+56@128+64@192+23@2281+8@4344+162@5726+162@7262+162@8798+162@10334+162@11870+162@ 13406+8@15608+8@17656+8@19704+162@21086+162@22622+418@24158 [ 596.444254] cma: [ 596.454008] cma: __cma_alloc: reserved: alloc failed, req-size: 350 pages, ret: -16 [ 596.454045] cma: number of available pages: l: [ 596.454052] cma: range 0: 3@109+56@128+64@192+23@2281+8@4344+162@5726+162@7262+162@8798+162@10334+162@11870+162@ 13406+8@15608+8@17656+8@19704+162@21086+162@22622+418@24158

homeassistant ?

Maybe my firmware build can replace Petitboot?

Exactly Since I don't know the build, I can't make any concrete statements about it. It is also not possible under any circumstances, as the access procedures are far too complex to be meaningfully encoded in the MASK-ROM. As firmware devices, only SPI flash, MMC (eMMC, SD card), and USB with a proprietary protocol are available. This is correct. I just quickly built this version out of curiosity. I was just about to provide the binary artifacts when I quickly took a look at the schematic of your device. If I am not misinterpreting the schematic, your device only allows the fixed SPI-MMC-USB sequence and the forced immediate proprietary USB device. This means that you cannot execute the firmware completely from the microSD card, for example, if there is still a valid firmware signature in a device (SPI, eMMC) that is higher up in the priority list. It is therefore essential that you are familiar with the USB recovery procedure (MASK-ROM-MODE), in case something goes wrong during the firmware experiments with the higher prioritized devices (SPI, eMMC).

Hello everyone! I’m new to the forum and recently set up Armbian on my Orange Pi using the latest July 2025 image. I’m working on a user-space application to monitor fuel consumption for IoT projects involving vehicle fleets, like optimizing diesel trucks. I’m thinking of something that could run via armbian-config or as a Python script, pulling data from fuel sensors. So far, my idea is to log consumption data and calculate efficiency based on user input. I’ve tried Grafana, but it lacks a dedicated fuel calculator—kalkulatorpaliwa.com.pl could serve as a starting point for a simple interface. I’m unsure how to approach this on Armbian—should I use Python with Matplotlib, or go for a lighter option like Bash with awk? I’ll share a basic startup script if someone helps me get started! What tools do you recommend for building such apps on Armbian? Has anyone worked on a similar fuel monitoring project with SBCs? What challenges might I face with sensor integration? Looking forward to your suggestions—I plan to start testing this week!

Yes I have the heat sink and a thermal pad: Time CPU load %cpu %sys %usr %nice %io %irq Tcpu C.St. 19:42:28 816 MHz 0.00 0% 0% 0% 0% 0% 0% 51,6 °C 0/4 19:42:33 816 MHz 0.00 0% 0% 0% 0% 0% 0% 50,5 °C 0/4 19:42:38 816 MHz 0.00 0% 0% 0% 0% 0% 0% 52,8 °C 0/4 Armbian 23.02.2 Bullseye with Linux 5.15.93-sunxi Ambient temp is quite hot these days it's like maybe 32°C maybe more

https://wiki.kobol.io/helios64/files/psu/YHY_12V_PSU_Specification.pdf

I was able to get the conflicting versions fixed: now:

Getting into kernel development can be daunting. There are layers upon layers of knowledge to master, but no clear roadmap, especially when it comes to debugging drivers or navigating userspace-kernel issues. View the full article

Does anyone know of a compatible image for the MXQ PRO 4K 5G TV Box with Allwinner H3, model Q44_V4.1_20210120? I've searched a lot and only found images compatible up to version V4.0. Since mine is V4.1, I haven't been able to get a successful boot from the SD card. If anyone has any tips, a working image, or experience with this specific model, I’d really appreciate the help!

Providing logs with armbianmonitor -u helps with troubleshooting and significantly raises chances that issue gets addressed.

Hi everyone, I’m experiencing a recurring and very specific issue with my TX2 TV Box, with the following specifications: SoC: Rockchip RK3229 RAM: 2GB DDR3 Storage: NAND flash (not eMMC!) Board: Generic TX2 board 🛑 Main Issue The system shuts down abruptly at exactly 29 minutes and 47 seconds of uptime (i monitoring via htop). It always shuts down at this time. It’s not a clean shutdown or reboot — it behaves as if the power was cut off. No meaningful logs appear in journalctl or dmesg, and the shutdown is instantaneous and silent. 🧪 What I’ve Tried: Disabled idle and sleep functions: Masked systemd-logind Set IdleActionSec=0 and HandlePowerKey=ignore Tried different kernel versions: Legacy: Armbian 22.02.0-trunk Focal legacy 4.4.194 Mainline: Armbian Jammy kernel 5.15 Attempted to disable the watchdog: Boot parameter nowatchdog Kernel parameter rcu_cpu_stall_timeout=0 Created a systemd service to periodically write to /dev/watchdog Tried to remove dw_wdt module (modprobe -r), but it either auto-loads or refuses to unload (watchdog did not stop) Tried building a custom kernel with CONFIG_DW_WATCHDOG=n, but the process failed due to gcc-arm-linux-gnueabi toolchain issues. Used config-rk322x to properly set RAM, NAND, and Wi-Fi chip before first boot + update/upgrade. Tried adding sudo systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target ⚠️ Additional Critical Note: The system does not work at all when flashed to eMMC/flash — only boots properly from NAND or SD card. Any image written to internal flash does not boot. Therefore, booting from NAND is required, which may be related to the watchdog being active by default on NAND-based boards. ❓ My Question: Has anyone with a TX2 or RK3229-based NAND board experienced this same issue? Is this a known watchdog timer issue on NAND models? Is there any stable image or device tree overlay known to work for this configuration? Any tips to fully disable the watchdog either via software or kernel patch? Thanks in advance for any help or suggestions!