Active threads

Didn't warn ffmpeg from a guts feel years ago that they will issue a takedown if no action is taken? So I'm not surprised. Kind of.

I don't have this hardware. However the last merged PR messing with code for this board/SoC was tested by Igor and he stated it boots just fine.

Interesting question. The dxf says the part in question is labeled ED1 besides CP18 and CP14. I found both CP18 and 14 in the schematics but ED1 not. Either mislabeled or I didn't catch it. https://x.na4.eu/KOTu3/quzevoji80.jpg OrangePi-Schematic of ZERO3.pdf

Here is the output: U-Boot SPL 2024.01_armbian-2024.01-S866c-P6b16-Ha5c2-V7d7d-Bbf55-R448a (Dec 22 2025 - 03:39:51 +0000) Note that prior to this I tried to update uboot through armbian-install, it did not change anything to my reboot issue.

I believe I'm having a similar issue. I'm running the Renegade Rockchip Libre Computer ROC-RK3328-CC-V1.3-8 and I've tried 6.12.32-current-rockchip64 as Debian IOT Minimal and as the Ubuntu Server versions from https://www.armbian.com/renegade/. Unfortunately the onboard ethernet phy is not working but I can use a USB ethernet just fine. I'm not super sure where to start troubleshooting other than a binary search for the version that broke things. If more info is needed from my setup I'm happy to post, let me know.

That the Helios64 SW/firmware did sequencing of 3.5inch HDD spin-up is indeed a good method to limit the maximum current draw. I do not know how power architecture is done in Helios64, but w.r.t. 3.5inch disks, so the 12V power need, you might avoid letting the current of the 12V flow through the SBC/motherboard. It is not needed, there might be connectors, still it is not needed. Even for traditional x86 PCs, 12V (and 5V as well) comes straight from the PSU, that is 100-1000W or so usually. The 12V also does not need to be exactly 12V, I feed a 4TB WD HDD from a 12V car battery in the field, is solar powered and 10 years old or so. Due to battery wear out, it sees a voltage of 10.5-14 Volts or so. No problem. 5V for SBC and some other small stuff is via a 3A DC/DC module. A car battery (72Ah or so) should have no issue with spinning up a handfull of 3.5inch HDDs simultaneously. The PCIe-to-SATA chips support hotplug, so you could use some P-MOSFETs or so to have GPIO-controlled powerswitch, but is of course electronics circuit design and soldering etc. Also maybe think if you need all that 5 HDDs (and at the same time) and with a RK3588 SoCo that can go as low as 1.5Watt idle. 5 spinning disks is 20W or so.

@Nick A, @MeJune Luckly. On this thread: https://forum.manjaro.org/t/allwinner-h728-a523-a527-t527-initial-support-thread/173654/2 He working for a year to make the linux working stable on this box. This mean kernel, dtb, ... can be replace on armbian build. I super need new image for web-service hosting purpose. Hope all function working.

My NanoPi-R6C came with FriendlyWRT pre-installed (OpenWRT variant) and I bought it 2 years ago partly also because I had a Samsumg 970 Evo NVME that needed a computer wrapped around it. I do not use images, instead root-filesystems (Btrfs). I Initially kept the FriendlyElec U-Boot, with all rest on NVME. Now still use the same principle, but EDK2-UEFI v1.1 as bootloader in eMMC and Armbian Trixie or Opensuse Tumbleweed with Armbian kernel and grub-efi. With latest u-boot (2026 rc2) I get no HDMI audio. I thought it was a power/reset issue, but also later tested again with complete un-powering first, but then also no HDMI audio. It might simply be a latency issue. Both older U-Boot and even much older FriendlyElec U-Boot as well as EDK2-UEFI initialize HDMI before the kernel and do simple 1080p60, so you also see the kernel being loaded, before KMS (re)-inits the HDMI. EDK2-UEFI has GUI for its settings, so no surprise it works there. For Jellyfin, I currently use a ROCK5B Armbian Trixie with Armbian vendor 6.1.115 kernel (also EDK2-UEFI bootloader). There were some issue with Jellyfin strreaming/transcoding, also on N100, I currently don't know why/what. The jellyfin-ffmpeg via CLI works great though, so about 5x realtime transcoding HEVC->H264. But Firefox on N100 or x5-Z8350 uses HEVC HW decoder, so no real need to do transcoding for me. LibreElec a month ago or so on NanoPi-R6C temporary booted from SD-card did do HW decoding OK, except for VP9 it was artifacts, not usable actually. So there is unfortunately no easy 1-size-fits-all currenlty. You can scan the forum, there are people who took unfinished patches and use very latest unstable Debian stuff, then things might work same as for x86.

Easiest approach is the customize-image.sh script in userpatches/. https://docs.armbian.com/Developer-Guide_User-Configurations/#user-provided-image-customization-script

Finally, build successful on Ubuntu Noble.😃

moved to feedback

This spi-mcp251x.dts made me use can0 with SEENGREAT Dual-CH Can Hat on latest Armbian v25.11.2 for BananaPi BPI-M4-Zero running Armbian Linux 6.12.58-current-sunxi64: /* * Device tree overlay for mcp2517/18 @ can0 on SPI1.0 (BananaPi Zero M4) / Works with SEENGREAT Dual-CH Can Hat (can0 only) */ /dts-v1/; /plugin/; / { compatible = "allwinner,sun50i-h616"; fragment@0 { target-path = "/"; __overlay__ { can0_osc_fixed: can0_osc_fixed { compatible = "fixed-clock"; #clock-cells = <0>; clock-frequency = <16000000>; }; }; }; fragment@1 { target = <&pio>; __overlay__ { can0_pin_irq: can0_pin_irq { pins = "PC2"; /* Pin 22 on BananaPi BPI-M4-Zero */ function = "irq"; bias-pull-up; }; }; }; fragment@2 { target = <&spi1>; /* Use SPI1 */ __overlay__ { #address-cells = <1>; #size-cells = <0>; mcp2518fd@1 { compatible = "microchip,mcp2515"; reg = <0>; /* Use SPIx.0 */ pinctrl-names = "default"; pinctrl-0 = <&can0_pin_irq>; spi-max-frequency = <10000000>; interrupt-parent = <&pio>; interrupts = <2 2 0x08>; /* PC2 IRQ_TYPE_LEVEL_LOW */ clocks = <&can0_osc_fixed>; status = "okay"; }; }; }; }; Create file: sudo nano /boot/dtb/spi-mcp251x.dts Add overlay: sudo armbian-add-overlay /boot/dtb/spi-mcp251x.dts Edit armbianEnv.txt: overlays=bananapi-m4-pi-5-6-i2c0 bananapi-m4-sdio-wifi-bt bananapi-m4-spi1-cs0-spidev spi-mcp251x param_spidev_spi_bus=1 dtparam=spi=on param_i2c_arm_baudrate=10000 I did not try to get can1 to work since I don't need it at the moment. I hope it helps. Have fun!

I’ve been testing Armbian on an Amlogic-based TV box, and wanted to share a short user experience. The device originally runs Android, but thanks to the Amlogic S9xx platform, it can boot Armbian from an SD card without touching the internal firmware. In my case, the system booted reliably and was usable for basic tasks like SSH access, light services, and general Linux testing. Ethernet and USB worked out of the box, while Wi-Fi and power management still required some manual tweaks, which seems common for community-supported TV boxes. For reference, the hardware I used belongs to the category of Amlogic TV boxes that are widely available on the market. These devices are not officially supported by Armbian, but they can still be interesting low-cost platforms for learning, testing, or small home projects. I’m curious if others here have experience with Armbian on similar Amlogic TV boxes, and which SoCs or configurations worked best for you.

I see. Is this a hardware enforced security feature of sort? Because according to: https://docs.u-boot.org/en/latest/board/amlogic/boot-flow.html, the s905x2 can read the bootloader from sd card no matter the configuration. Only the order differs. I'm now trying to compile u-boot down from BL2 up to BL33 using this closest match of a board. It has a ddr4 memory while mine is ddr3l, but as shown in the doc it also includes ddr3 firmwares so I *hope* this will work. https://docs.u-boot.org/en/latest/board/amlogic/sei510.html However, if I'm talkin nonsense please let me know. This is my first dive into u-boot or bootloaders in general.

Wow, thank you for this comprehensive answer. It will probably take me about as much time as until 6.19 is released to try and understand it 😂 Why does this say archlinux? And also, where to get these "idbloader.img" and "u-boot.itb" files from? The console is ttyS0, it works.

@Lesano https://linux-sunxi.org/Tanix_TX1 shouldn’t be hard to make a armbian config for this board since it's mainlined. You probably want this patch to add wifi and hdmi. https://gitlab.manjaro.org/iuncuim/linux/-/blob/eccecabc2ca2d6efb463edc94aa0ef383d8ae200/0650-arm64-dts-allwinner-h313-Tanix-TX1-TVbox.patch You would need to boot over USB cable. I never booted over USB so I can't help with that. https://linux-sunxi.org/FEL/USBBoot

I couldn't find this documented specifically, but I confirmed this was the case via testing. Google also provided an AI summary which also stated that this was the case. I enabled `iptables-legacy` in the Armbian kernel builder which then resolved the errors I was getting. I also eventually realized through further research that `nftables` were also supported and available as a module out of the box. I wound up changing my Microk8s config to use `nftables`, which also worked out and is where I left my config today. Hopefully this is helpful for someone else in the future. Somewhat relevant articles: https://github.com/canonical/microk8s/issues/2180 https://github.com/canonical/microk8s/issues/4387 https://hub.libre.computer/t/missing-iptables-kernel-configs-for-microk8s-calico/3717

i also tried installing network manager separately, however it is not able to override the wifi configurations. It was allowing in image files few months ago. But now it does not allow.

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

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)

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

@robertoj I apologize, perhaps you missed the message.

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