Active threads

There are schematics available of this device, so one could get a hint from those, but depends if you have electronics background or not. To me it seems that higher level software in Debian/Linux enables power management handling all the way using info it gets from the power management chip/circuitry. You can guess that for this device, same as smartphone, battery operation is considered primary/essential, so decision is 'low-batt' and shutdown. I have a BananaPi M1 that also has LiPo charging, but that is DIY soldereing, so no OS component bothers with not-connected cell, but if a cell is connected/soldered which I did, is charges and runs on that cell if microUSB PSU (they call it 'AC' in the chip signal names) is disconnected, although its SATA port is unpowered then. Runs Armbian Trixie CLI only (eth + serial console). An old business HP 2-core laptop that I got without battery and HDD runs fine on just the original HP power adaptor (has 3rd wire for some genuine HP charger purposes). For USB-C powered devices, there might be many things to deal with, e.g. my ROCK5B after un-boxing goes in a bootloop with a RPI5 PSU, was/is know, so I feed it with own 12V USB-C pig-tail. The Pinebook might do well if you fake the battery, so look at colored wire/connector. I have used that several times in the past decades. The yellow wire might be for temperature so besides a proper voltage on black and red, you also need to do something with the yellow wire I guess.

Yes, but I haven't test it. I used pre-flashed to boot my image and I am done with this board / platform. Someone else has to take it from here. If board gets maintained status, this will start working automatically. Links point to our servers where this board images are not present - we only keep supported on our servers, for things we know they at least boot.

The rk3588 soc has a fixed boot order which is spi, emmc, microsd, other I think. So if there is a boot loader found on spi it will ignore other options and try to boot from that. While Armbian uboot binaries on spi are instructed to check if there is a microsd card inserted and boot from that, vendors can (ab)use this circumstance to make it harder for other operation systems being used because tools like rkdevtool are necessary to get rid of it. If the spi is pre-flashed with crap, I guess that's why the step is necessary.

😄

I believe it was android I don't care what os it has just want to get it to work again

@AndroidNewbie Do you have the image of the box?

Hi, I’m working on enabling I²S audio output using a PCM5102 DAC on an Orange Pi Zero 2W (SoC: Allwinner H618) running Armbian_community_25.11.0-trunk.334_trixie_current_6.12.47_minimal. Despite several tests and rebuild attempts, I haven’t been able to obtain any sound output from the I²S interface. Below is a summary of what has been done so far. Hardware setup Board: Orange Pi Zero 2W SoC: Allwinner H618 DAC: PCM5102 (I²S input, analog stereo output) Connections: I2S0 → used for DAC (pins LRCK, BCLK, DIN, GND, 3.3V) Confirmed pin mappings according to H618 documentation and available DTS files. OS Image: Armbian_community_25.11.0-trunk.334_Orangepizero2w_trixie_current_6.12.47_minimal What has been done 1. Kernel confirmed to be mainline-based (6.12.47-current-sunxi64). Linux orangepizero2w 6.12.47-current-sunxi64 #1 SMP aarch64 GNU/Linux 2. Checked kernel symbols to verify presence of sunxi audio modules: Shows sound/soc/sunxi/sun8i-codec.c among others. Created a custom overlay at /boot/overlay-user/sun50i-h618-i2s0-pcm5102.dtso, based on examples from sun8i boards, with simple-audio-card referencing the i2s0 controller. Enabled overlay in /boot/armbianEnv.txt : user_overlays=sun50i-h618-i2s0-pcm5102 Rebooted and verified device tree loading → No audio device or sound card is registered. Also tried with predefined overlay sun50i-h618-i2s2-pcm5102 included in the Armbian tree → no sound card detected (aplay -l returns “no soundcards found”). Findings It seems that the H618 SoC has no upstream audio codec driver (unlike H616 which includes sun8i-codec). The I²S controller node exists in the mainline kernel sources, but may not be fully supported or linked to a DAI (Digital Audio Interface) for external DACs. simple-audio-card bindings appear to compile correctly in the overlay, but the device never registers in ALSA. Questions Is there any working DTS overlay or patch enabling I²S output (no internal codec) for the H618 platform? If not, what would be the correct approach — patching the DTS at kernel source level or adding a compatible binding manually? Has anyone successfully used a PCM5102 (or similar DAC) with the H618-based boards under Armbian? My goal To have a functional stereo I²S audio output through PCM5102 (or any compatible DAC), recognized as an ALSA sound card in Linux. Any help, hints, or working overlay examples would be greatly appreciated. Thanks in advance for your time and expertise! Jose Cardoso

Please help, I'm stucked (or, may be stupid). I use my tv-box as printserver (Klipper), it works fine. Now I attempt to use accelerometer ADXL345 usb board, and I havnt success. It must be simple task, but something went wrong here. Board works, flashed normally without any errors and shown as should by lsusb: klipper@transpeed-8k618-t:/usr/lib/udev/rules.d$ lsusb Bus 003 Device 002: ID 1a86:7523 QinHeng Electronics CH340 serial converter Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 013: ID 1d50:614e OpenMoko, Inc. rp2040 Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Also, it must be appear as serial device, but... klipper@transpeed-8k618-t:/usr/lib/udev/rules.d$ ls -l /dev/serial/by-id total 0 lrwxrwxrwx 1 root root 13 Nov 8 18:47 usb-1a86_USB_Serial-if00-port0 -> ../../ttyUSB0 ...here is my "Ender" only. dmesg: [30617.149526] usb 4-1: new full-speed USB device number 22 using ohci-platform [30617.358206] usb 4-1: New USB device found, idVendor=1d50, idProduct=6177, bcdDevice= 1.00 [30617.358227] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [30617.358235] usb 4-1: Product: rp2040 [30617.358242] usb 4-1: Manufacturer: katapult [30617.358249] usb 4-1: SerialNumber: E6647C7403433637 [30663.467079] usb 3-1: new full-speed USB device number 3 using ohci-platform [30663.665820] usb 3-1: New USB device found, idVendor=1a86, idProduct=7523, bcdDevice= 2.64 [30663.665867] usb 3-1: New USB device strings: Mfr=0, Product=2, SerialNumber=0 [30663.665891] usb 3-1: Product: USB Serial [30663.668223] ch341 3-1:1.0: ch341-uart converter detected [30663.680198] usb 3-1: ch341-uart converter now attached to ttyUSB0 I've search solutions, but have not resolve.

I gave some information ..... Hit:8 http://fi.mirror.armbian.de/beta bookworm InRelease ? 🙂

I tried rebuilding the Device Tree as suggested in other forums. No Joy!! Still can't get it to work. Also added i2c-dev module but that isn't showing in lsmod. Help appreciated. Clearly I am missing something here. This shouldn't be difficult. :-)

Ok, looks like I just missed the special instructions about the recovery button. ☹️

Apparently, there are more versions of the box. One has two stars on the nameplate and "V 1.4" printed on the PCB. Although WiFi works on version 1.2, if does not work on this version V1.4 has a different Wi-Fi chip: EA6521. dmesg | grep 'SDIO' gives: [ 9.621165] mmc2: new ultra high speed SDR104 SDIO card at address 8800

> drop them. > drop it. sorry. Someone is dropping something here I'm not sure if support was ever better or downgraded at one point because it never had it's own page on the site, it's just a mention of a device tree file swap under orange pi 5, which is listed as standard. If it's not different enough to warrant it's own page, it's entirely reasonable to think it is supported as much as the orange pi 5, under which it can be found. The max, plus and pro variants all have their own pages. 🤷‍♂️ I do understand how tooling works, as I've spend enormous amounts of time digging through the repo and modifying it. Mix and matching patches, modules, or loaders from other projects where their stuff works , and armbian's doesnt or visa versa, to get full functionality images across for the 6 different sbcs I've got. Often times certain projects will have things like vpu figured out way before other projects.

Thanks for the update. I really appreciate your help.

Continuing the story. Or 4pda (Russian).

If you have patience, CEC may work at some point with mainline kernel. There is not fast solution.

See There is an issue with the build framework that prevents base-files from being built for the arm64 target. At present time the issue is unresolved, and the root cause might be still unknown.

https://github.com/armbian/os/commits/25.11.0-trunk.367/git_sources.json This file determine state (hash) of sources. It's not a straightforward process, but one can recreate exact image (except userspace packages, which versions are not stored) This file has to be here https://github.com/armbian/build/commit/31e82512cc60a74f56b710aa2971d7dc2beec9b9 One day, this will be done better Sadly there is too much of such e-waste and way way too little people willing to maintain them in their limited private time. I am sure you can find a working image somewhere in our archives so you don't need to throw it away, but we cannot fool you & ourselves to be able to keep this board maintained.

@erebus041 @Nick AOne small detail: I've used etchdroid and drofus to burn my sd card.

Ok. Also I think these are wrong for the PI5: dtoverlay=disable-wifi dtoverlay=disable-bt I believe it's: dtoverlay=disable-wifi-pi5 dtoverlay=disable-bt-pi5 My notes on this: # Pi3 / ZERO2W dtoverlay=pi3-disable-wifi dtoverlay=pi3-disable-bt # PI5 dtoverlay=disable-wifi-pi5 dtoverlay=disable-bt-pi5 # Everything else dtoverlay=disable-wifi dtoverlay=disable-bt Back in the day, I read somewhere that Bluetooth can inhibit serial from functioning correctly on the Pi's. I've never seen it happen, but maybe using the wrong overlay is hindering it in some way? Worth looking into.

I just noticed from your screenshot that you aren't using Armbian. You need to ask support questions for non-armbian software from where you got your software. Ophub is a fork of Armbian that used the Armbian name without permission. They do not contribute to Armbian development nor do they contribute the these forums.

Armbian Trixie XFCE (Edge kernel 6.18.0-rc3-edge-rockchip64) + Stable mesa 25.0.7-2 + box64-rk3588 0.3.9+20251106.dcd3ba0-1 (https://ryanfortner.github.io/box64-debs/) + wine-10.18-staging-tkg-amd64-wow64 (https://github.com/Kron4ek/Wine-Builds/releases) + dxvk-sarek v1.11.0-sarek-async-writeaccessfix-malifix-5d21d2b (https://github.com/pythonlover02/DXVK-Sarek/actions) Elin ~40fps@720p

Hip hip hooray !!! Yep, this way worked. Will provide the all steps for people who have the same issue. $ apt install linux-u-boot-rock-5b-edge $ armbian-install # Just in case I've installed to the all partitions. I mean to 5th and 7th. > 5 Install/Update the bootloader on SD card (/dev/mmcblk1) > 7 Install/Update the bootloader on MTD Flash $ reboot And now I can enter to uboot shell change to F2: 1068MHz ch0 ttot12 ch1 ttot12 ch2 ttot12 ch3 ttot12 change to F3: 1560MHz ch0 ttot14 ch1 ttot14 ch2 ttot14 ch3 ttot14 change to F0: 2112MHz ch0 ttot16 ch1 ttot16 ch2 ttot16 ch3 ttot16 out U-Boot SPL 2024.04-armbian-2024.04-S830c-P0000-Hd72c-Vdfa5-Bb703-R448a (Oct 24 2025 - 02:33:30 +0000) Trying to boot from SPI ## Checking hash(es) for config config-1 ... OK ## Checking hash(es) for Image atf-1 ... sha256+ OK ## Checking hash(es) for Image u-boot ... sha256+ OK ## Checking hash(es) for Image fdt-1 ... sha256+ OK ## Checking hash(es) for Image atf-2 ... sha256+ OK ## Checking hash(es) for Image atf-3 ... sha256+ OK INFO: Preloader serial: 2 NOTICE: BL31: v2.3():v2.3-868-g040d2de11:derrick.huang, fwver: v1.48 NOTICE: BL31: Built : 15:02:44, Dec 19 2024 INFO: spec: 0x1 INFO: code: 0x88 INFO: ext 32k is not valid INFO: ddr: stride-en 4CH INFO: GICv3 without legacy support detected. INFO: ARM GICv3 driver initialized in EL3 INFO: valid_cpu_msk=0xff bcore0_rst = 0x0, bcore1_rst = 0x0 INFO: l3 cache partition cfg-0 INFO: system boots from cpu-hwid-0 INFO: disable memory repair INFO: idle_st=0x21fff, pd_st=0x11fff9, repair_st=0xfff70001 INFO: dfs DDR fsp_params[0].freq_mhz= 2112MHz INFO: dfs DDR fsp_params[1].freq_mhz= 528MHz INFO: dfs DDR fsp_params[2].freq_mhz= 1068MHz INFO: dfs DDR fsp_params[3].freq_mhz= 1560MHz INFO: BL31: Initialising Exception Handling Framework INFO: BL31: Initializing runtime services WARNING: No OPTEE provided by BL2 boot loader, Booting device without OPTEE initialization. SMC`s destined for OPTEE will return SMC_UNK ERROR: Error initializing runtime service opteed_fast INFO: BL31: Preparing for EL3 exit to normal world INFO: Entry point address = 0xa00000 INFO: SPSR = 0x3c9 ns16550_serial serial@feb50000: pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19 U-Boot 2024.04-armbian-2024.04-S830c-P0000-Hd72c-Vdfa5-Bb703-R448a (Oct 24 2025 - 02:33:30 +0000) Model: Radxa ROCK 5 Model B DRAM: 16 GiB Core: 353 devices, 32 uclasses, devicetree: separate MMC: mmc@fe2c0000: 1, mmc@fe2d0000: 2, mmc@fe2e0000: 0 Loading Environment from SPIFlash... SF: Detected xt25f128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB *** Warning - bad CRC, using default environment In: serial@feb50000 Out: serial@feb50000 Err: serial@feb50000 Model: Radxa ROCK 5 Model B rockchip_dnl_key_pressed: no saradc device found Net: No ethernet found. Hit any key to stop autoboot: 0 => Great Thanks a lot

Hi I'm looking to emulate an industrial device such as eWon or ESA router by using an sbc with dual eth and tailscale/headscale. What is the best and cheapest board? better if with a decent chassis. I'm interested in something like nanopi Rx or orangepi Rx. Any idea? thank you

I see from https://github.com/nextcloud/nextcloudpi/releases that 'pi' is sort of a synonymy for 'ARM SBC' or pre-installed images. 'pi' is great but a problem as it is not generic arm64 so every SBC flavor needs a 1GByte zip image just for a different kernel and bootloader. Same as long time ago I used a 'pi' script to get Node-RED installed in an x86 Debian Bullseye Virtual Machine (so just 'Debian' actually), I would focus on generic solutions. Armbian is doing very well w.r.t. alignment and portability, so the SoC or SBC does not really matter, as long as it is compliant with Debian ARM64. For Node-RED on Opensuse-Tumbleweed ARM64 I needed to hack the script a bit to fake a compliance check, but with that, it also worked. It saved an enormous amount of effort re-installing OS etc. So bottom line is, maker sure you don't lock yourself into a certain SBC or SoC, but make sure it is standard generic ARM64 (or standard x86-64, which is already the case for years) A way to keep your current installation is to 'virtualize' it: What runs on the Odroid or RaspberryPi or other SBC from SD-card or eMMC or NVME or SSD can be made EFI bootable and then it will run as virtual machine on the same SBC or other new/faster SBC of course as well. I have done this for RPI3B functions -> RPI4B in the past (also 32-bit VM in 64-bit host, Pi-Hole for example) and this year again to replace RPi4B-8GB with ROCK5B-16GB. It is beyond the scope of this topic, but start with installing 'virt-manager' and try to boot and Armbian-UEFI image/instance. Or see: https://github.com/nextcloud/vm I haven't used 'cloud' since owncloud, but right now, if I would certainly start with a VM. Same for e.g. HAOS, runs fine in a VM on ROCK5B. You do not need proxmox, all is build-in in Linux already.