All Activity

I tried installing it to the internal eMMC memory, and now it won't boot. It looks like it'll have to stay on the SD card—or is there a way to install it?

Hi all, After a recent update bumped the current kernel to the 6.18 series, the rear 3.5mm jack on my NanoPC-T6 LTS stopped playing any sound. I'm connecting it to an external amplifier that worked fine before the update. What I see on 6.18 (6.18.35-current-rockchip64): The audio card (rt5616) still shows up in aplay -l and playback commands run without errors, but no sound comes out. Volume levels and mute aren't the issue — I checked those. What fixed it: downgrading via armbian-config to linux-image-current-rockchip64=25.11.2 (kernel 6.12.58). With 6.12 the audio works perfectly again. So 6.12 works and 6.18 doesn't, at least on my board. Is anyone else seeing this on a T6 / T6 LTS with the 6.18 current kernel? Happy to share any logs or run commands if it helps to narrow it down. Thanks!

Thank you for moving my post to the appropriate section. I apologize for posting in the wrong area initially. To reiterate my question for this General forum: I have a Skyworth TV box with a Realtek RTD1325. I am looking for any guidance on whether it is possible to run Armbian on this hardware, even experimentally. Has anyone here worked with similar Realtek-based devices, or could someone point me toward resources for building a custom image for the RTD13xx family? I understand this is outside the usual supported hardware, but any advice would be greatly appreciated. Thank you.

Hi SymbiosisSystems, Same problem like you with kernel 6.18.35 and 6.18.37, all it's Okok with 6.18.10 like I said in this post:

moved

moved

Hello everyone, I am hoping to get some advice on the possibility of running Armbian on a TV box I have. I understand this is a niche device, and I am new to this process, so any guidance would be greatly appreciated. Device Information: Device Type: TV Box Manufacturer: SkyworthDigital Model: SK Hailstrom Ref 1325 Board: HPR3E1325_4k Hardware/Platform: rtd1325 Product: HPR10X Hardware Details (from system info): Core Architecture: 4x ARM Cortex-A55 @ 1700MHz Instruction Set: 64-bit ARMv8-A (32-bit Mode) Supported ABIs: armeabi-v7a, armeabi Scaling Governor: schedutil I have done some preliminary research and learned that official Armbian support for Realtek SoCs is not available. However, I noticed that there is some ongoing community development for the RTD13xx family. My questions are: Has anyone had any success with a similar Realtek RTD1325 device? Would it be possible to adapt an existing build (perhaps one intended for the RTD1319) to work with this hardware? If so, what would be the main challenges (e.g., DTB files, drivers)? Could someone point me toward the best resources or forum threads for building a custom Armbian image for this kind of Realtek platform? I have experience with the command line and following technical guides, but I am not a developer. I am prepared for the possibility that this might not be feasible, but I am eager to learn and experiment. I will, of course, proceed with caution regarding the risks (e.g., bricking the device). Thank you in advance for your time and expertise. Additional Context: I have the device rooted and can access ADB.

Hi Taz! I am trying to replicate your success with booting Debian Trixie on the Teclast T60AI tablet using the Radxa OS vendor kernel (6.6.98-vendor-sun60iw2 from the Radxa-cubie-a7z-v0.6.4 build). I am very close, but I've hit a dead end with a kernel panic on the very last stage of the boot process. I would really appreciate your advice on how you bypassed this. [ 10.852267] EXT4-fs (sda28): mounted filesystem ... [ 10.866540] VFS: Mounted root (ext4 filesystem) readonly on device 259:12. [ 10.875759] devtmpfs: mounted [ 10.881784] Freeing unused kernel memory: 1920K [ 10.887909] Run /sbin/init as init process [ 16.097167] request_module: modprobe binfmt-0000 cannot be processed, kmod busy with 50 threads for more than 5 seconds now [ 16.102268] Kernel panic - not syncing: Requested init /sbin/init failed (error -8).

My fix for what I was trying accomplish, which was to run Armbian Debian with vendor kernel with nvme boot, was to install the mainline kernel change the kernel with Armbian-config and then reinstall with option 2 'Boot from MTD; system on nvme'. Installing with this option to begin with instead of trying to flash the boot loader on MTD after the fact may have been the better choice.

for that price and feature set the odroid c4/c5 and the orange pi 5 (or 5b with onboard emmc) are the usual sweet spot. if you want zigbee i'd lean toward a board with proper usb (not just the otg ports some of the cheaper ones have) so your zigbee stick gets a clean port and a decent antenna position. one thing worth saying upfront from experience: skip the sd card for anything thats writing 24/7 like home assistant's database or pihole logs, you already know this but emmc or a small ssd over usb3 will save you a ton of corruption headaches down the line. and budget a few euro for a heatsink, the rk3588 boards in particular will thermal throttle in a closed case without one. for the support angle werner's spot on, sticking to standard/platinum boards on the download page means kernel updates keep coming and you're not chasing a dead community image in a year. raspberry pi 4/5 is the boring-but-safe option if you can stretch the budget, just because the software ecosystem assumes it exists. on the software side, since youre running pihole + HA + zigbee you'll basically be living in docker, which armbian-config can set up for you. if you ever want the rest of the self-host stack (nextcloud, file sync, vpn back in) without hand-rolling reverse proxy and certs, full disclosure im involved in an open source project called syncloud thats basically a thin layer that does one-click app installs and handles https/auth/updates for you on arm boards. its not for everyone, if you enjoy wiring up nginx and docker-compose yourself you'll probably find it too hands-off, but for a set-and-forget home box it takes the fiddly parts off your plate. either way the boards above will serve you well.

Hi, thank, I forget this method. new result... same with 6.18.37: With 6.18.10-current-rockchip64 and rk3399-kobol-helios64.dtb-6.18.18-opp dtb file, Ok With 6.18.37-current-rockchip64 and overlay helios64 patch with armbian-config, Ko With 6.18.37-current-rockchip64 and k3399-kobol-helios64.dtb-6.18.18-opp dtb file, Ko more information: On "Cold Boot": System blink red After "Reset": Same crash like without DTB file patch on previous Kernel like 6.18.10... I try edge with 7.1 kernel but not compile, finish with error during process. Back to 6.18.10 with dtb file patch and freeze with this stable config and kernel for this time, I don't have time to investigate more at this time. Have a nice day

To clarify my device currently boots but only off the micro sd card. I want to boot off the nvme.

Searching for testpoint for the MX10-L TVstick

I've ran into two issues. The first my board won't boot off the Armbian Debian vendor image. Second it boots off the mainline Debian image, but when I try installing the boot onto the MTD via option 7 in Armbian-install it completes, but I get a solid blue LED and a UART output that hangs on BL31: Preparing for EL3 exit to normal world -> Entry point address = 0x200000 -> SPSR = 0x3c9 then it hangs. Before this I tried manually erasing the SPI and loader and reinstalling them with rkdeveloptool, but this didn't help. I would provide the UART logs, but the server is failing at uploading images. I'm looking to boot off the nvme, but I'm not sure how to resolve this.

Thank you very much. Thanks to your detailed guide—as well as the one by "Chiều Nhạt Nắng"—I successfully installed Armbian on my TV box. I had struggled for a long time previously, following outdated instructions without fully understanding them; I kept unplugging and replugging the power cable, which ended up damaging the power IC (so now I have to use the USB port for power). However, thanks to your specific guidance (user 0757), I followed the steps and finally succeeded. Thank you!

Honestly, I've already forgotten what the problem was there. Most likely, I used the Armbian installer and specified where to install the distribution in the automatic image download mode. Before that, I had tried writing it manually. Besides that, I found an important nuance — if you install software through armbian-config, for example GNOME and Chromium, the Plymouth splash screen will be automatically configured at boot, and hardware video decoding will be enabled in the browser, which for some reason does not get enabled when installing manually.

Can I ask how did you fix it? I have the same problem but cannot get it to make it work.

moved to off-topic neither a supported device nor about Armbian.

Hi all, I'm running DietPi on an Orange Pi Zero 3 (H618, sunxi64), which repackages the Armbian current-sunxi64 kernel. I use a USB DVB-T2 dongle (HanfTek Astrometa RTL2832P, VID/PID 15f4:0131) with tvheadend for over-the-air TV. After a routine update the dongle stopped working entirely, and I tracked the root cause down to missing kernel modules. ## Problem Starting from kernel 6.18.x (package linux-image-current-sunxi64 version 26.05.0-trunk-dietpi1 and all subsequent builds through dietpi5), the following modules are absent from the kernel package: - dvb_usb_v2 - dvb-usb-rtl28xxu - dvb_core The USB device is correctly detected at bus level (lsusb, dmesg) but no driver ever binds to it and /dev/dvb is never created. lsmod | grep dvb returns nothing, and find /lib/modules/$(uname -r) -iname "*dvb*" only shows RC keymap files (e.g. rc-dvbsky.ko.xz), not the actual DVB subsystem drivers. lsusb output: Bus 004 Device 003: ID 15f4:0131 HanfTek Astrometa DVB-T/T2/C FM & DAB receiver [RTL2832P] dmesg shows the device is enumerated but no driver binds: usb 4-1: New USB device found, idVendor=15f4, idProduct=0131, bcdDevice= 1.00 usb 4-1: Product: dvbt2 usb 4-1: Manufacturer: astrometadvbt2 (no further DVB-related messages) ## Verified affected range I downloaded and inspected each linux-image-current-sunxi64 .deb from the DietPi apt repo without installing them, extracted with dpkg-deb -x, and searched for dvb_usb_v2.ko / dvb-usb-rtl28xxu.ko inside lib/modules/*/kernel/drivers/media/usb/dvb-usb-v2/. Results: 26.05.0-trunk-dietpi1 through dietpi5 (kernel 6.18.x) → DVB modules ABSENT 26.02.0-trunk-dietpi8 (kernel 6.12.76) → DVB modules PRESENT 26.02.0-trunk-dietpi1 through dietpi7 (kernel 6.12.58–6.12.74) → PRESENT 25.11.0-trunk-dietpi1 through dietpi3 (kernel 6.12.43–6.12.57) → PRESENT The regression is introduced exactly at the 26.02→26.05 branch transition (kernel 6.12→6.18). ## Kernel config comparison (confirmed) In kernel 6.12.76 (/boot/config-6.12.76-current-sunxi64), the full DVB-USB subsystem is present and compiled as modules, including: CONFIG_DVB_CORE=m CONFIG_DVB_USB_V2=m CONFIG_DVB_USB_RTL28XXU=m CONFIG_DVB_USB=m (plus ~40 additional DVB USB driver modules) In kernel 6.18.29 (extracted from linux-image-current-sunxi64_26.05.0-trunk-dietpi5_arm64.deb), grep for DVB_USB and DVB_CORE returns NO output at all — the options are not present in the config file, not even as "# CONFIG_DVB_USB_V2 is not set". This confirms the entire DVB-USB subsystem was dropped from the sunxi64-current kernel config when the 6.18.x branch was opened, not selectively disabled. ## Hardware Board: Orange Pi Zero 3 (Allwinner H618, sun50i-h618) Dongle: HanfTek Astrometa DVB-T/T2/C FM & DAB receiver [RTL2832P] VID/PID 15f4:0131 Kernel broken: 6.18.29-current-sunxi64 GCC 13.3.0 (aarch64-linux-gnu), build date 2026-03-05 Kernel working: 6.12.76-current-sunxi64 USB device descriptor (from lsusb -v): idVendor 0x15f4 HanfTek idProduct 0x0131 Astrometa DVB-T/T2/C FM & DAB receiver [RTL2832P] bcdDevice 1.00 iManufacturer 1 astrometadvbt2 iProduct 2 dvbt2 bNumConfigurations 1 bNumInterfaces 2 MaxPower 500mA ## Workaround Downgrading to linux-image-current-sunxi64=26.02.0-trunk-dietpi8 restores DVB support. Package pinned with apt-mark hold to prevent auto-upgrade. Note: the downgrade via apt-get install --allow-downgrades correctly swapped the kernel image and initrd, but did NOT regenerate the /boot/dtb-<version>/ directory nor update the /boot/dtb symlink — it was left pointing to the now-removed newer kernel's dtb directory, causing a boot failure. The dtb files had to be manually copied from /usr/lib/linux-image-6.12.76-current-sunxi64/allwinner/ and the symlink fixed by hand. This may be worth a separate look at the postinst/postrm scripts for the kernel downgrade case on sunxi64. ## Requested fix Please re-enable CONFIG_DVB_USB_V2=m, CONFIG_DVB_USB_RTL28XXU=m, CONFIG_DVB_CORE=m and their dependencies in linux-sunxi64-current.config for the 6.18.x branch. These were present throughout the entire 6.12.x series and there is no apparent reason to drop them. Thanks for the great work on Armbian!

Totally agree, too little or niche market! I 'm thinking about soldering simcard directly on these cheap minipci lte modem and use a regular usb2.0 cable, what a joke!

OK, I did not look into further details, I don't have any of this HW. I only have same experience 10 years ago, 4G module works in USB adapter, did not get it to work in mPCIE slot. I am not sure if a DeviceTree patch/change can fix it, don't know enough of that description principles. As indicated, SeeedStudio can read this, it is their HW, maybe they should fix it for you.

Thanks for your input, I never really use gpio lib and i don't know if gpio over i2c is userland playable or there are reserved to the kernel. The fact on the schematic is VSYS_3V3_EXP is the first rail powering up because it's supply I2Cs bus and the GPIO over I2C to switch ON or reseting thing. VCC5V0_DEVICE_S0 For FAN & HDMI & USB & TYPE-C, USB HUB (Total: 3A) switch on by RK806S over I2C (PMIC_PWR_CTRL2) VSYS_3V3_EXP For CSI & DSI & RPi 40Pin (Total: 4A) <======== I2Cs GPIO (LTE RESET), Minipcie is supplied here! , switch on by RK3576 gpio (VSYS_3V3_EXP_EN) VCC3V3_PCIE For PCIE-M.2 (nvme), switch on by RK3576 gpio (PCIE_PWREN_H_GPIO0B5) The design flaw is here : you need I2C up to put LTE modem (already on by the same I2C power supply) in reset state before switch on USB PHY, then release LTE_RESET. Why they didn't put LTE modem supply, triggering a 3.3vcc mosfet from USB 5V rail ready signal after usb init like normal usb device, too easy?

One thing that helped me in a similar situation was checking that the running kernel version matched the headers exactly with uname -r. A mismatch there can be really confusing. If you've recently upgraded the kernel, a reboot before installing the headers is worth trying too.

Hey guys, I just wanted some help from you regarding my X96Q. It is a 1+8GB Model with PCB Revision V1.1. It has a H313 processor but sunxi-fel reports H616. A few weeks ago I repaired the USB port of this box and I was successful in it and everything worked perfectly after that(the device booted up to android and worked perfectly) but Then I started to play with that Hidden button in AV port and I randomly clicked it and I thought it would be harmless but after that the device stuck in Red LED and didn't booted anything(possibly an EMMC Corruption). I tried Phoneix Suit first but it stuck on ram init. Then I brought a CP2102 Adapter to read the serial logs, and it turned out to be a Dram calibration errors where: Boot0 starts > Initializes The Emmc, the Board and the CPU -> Then the PMU(reported as AXP806 but physically AXP305) sets ram voltage to 1500mV -> Then it tries to Dram training -> fails and throws [...] "Read calibration error" multiple times —> keeps retrying until it gives up with "[...] Restraining final error." I investigated further and found that my emmc chip's critical sectors are corrupted. I used sunxi-fel to read the emmc and found that it fails to read after 16MB mark, means emmc got corrupted when I repeatedly pressed the AV port button. Now I tried a Armbian via sd card and it says: [...] Your Current DRAM Config isnt supported... Retrying... And keeps doing In a endless retry loop. Same for Miniarch, Armbian and many other builds... Any idea what's the problem with my box?

My thinking is that with a standard example tool from libgpiod (gpioset) it should be possible to toggle a GPIO line. I see 'P05' that seems a pad number of the RK3576. I remember I had to dig deep in internet fora for something similar for BananaPi M1 to see what to put in armbianEnv.txt. Or NanoPi-NEO. The later I use with those example gpioset to toggle a GPIO to switch some own electronics on/off. You could also use lgpio (rpigpio successor or any other that can toggle pin states). Note that formally, you need to threat a GPIO line like a file, claim, open, close etc. After that state is undefined, but most SBC kernels keep the state, but formally undefined. See many many discussions on wiringpi etc. W.r.t. this combPHY: the RK3576/RK3588: those can act as several SerDes, it is sort of multiplexed, so cannot be all at the same time. But you need to look in schematics. I use the SATA<> PCIE2x1 swap (on E-key slot on ROCK5B and ROCK3A) but it very much depends on what firmware/bootloader and DTB(O) and kernel. For the ROCK3A for example, I still don't have it working according to I wish with mainline based U-Boot+kernel. Only vendor 6.1 and legacy U-Boot. I see on the SeeedStudio page: preloaded with Armbian, so this topics is a sort of test-case IMO: is that claim with mainline based or vendor/legacy Rockchip; I guess the latter, so maybe list versions of various system software. 'Forky' is not released, so a moving target or rolling release, others don't know what versions you use so not possible to reproduce the issue(s).