Active threads

Many thanks for your replies. @Werner I can only say that I got the image via Armbian Imager, well designed for lazy people like me. This: On the Armbian Rock5 ITX web page, There are two candidates: 1 ) This one, because it's the only image in the list with variant "Gnome": or 2) this one, because it has the same size (1.4 GB), but doesn't say anything about the variant. The two images above have two different sha hashes. If it's true that isn't good for desktop (I agree with you because it doesn't work properly), I don't understand why it's tagged as "Recommended" on Armbian Imager. Anyway, I deleted everything and started from scratch, using another image tagged as "Recommended" based on Debian 13 and CLI only. This one is less complicated and till now works. @eselarm I tried two different monitors: the first one is quite modern as it supports not only many resolutions, but also different frequencies and other stuff. The second one is very basic: it can support up to 1980p at 60hz. In both cases, I got the same behavior. I also tried in the past EDK2-UEFI, but it didn't work very well on my Rock 5 ITX due to unexpected behaviors that I could not control in an effective way. That being said, unfortunately I don't have the exact filename and sha256sum of the previous image because I changed the image.

Yes you can work to make things better. But since I don't have this box (nor even one with that specific cpu version) there isn't anything I can really help you with. But anything you find/improve can be submitted back to Armbian as a PR. This stuff is all community supported, thus it depends on people like you to make improvements and submit them back for others to benefit from.

Thanks @JuanEsf

Hi Everyone, I managed to have it booted off the SD card only without FEL fiddling (also because my A-to-A OTG cable was dumb so I've soldered a UART and get on there trying to dodge the hardcoded protected boot on eMMC by playing with u-boot and tricking it with DTB hacks forcing an internal eMMC disable in favor of SD boot.) I've ultra simplified the procedure for mere mortals: 1- Flash Pine64 Armbian image on an SD card 2- Flash the "magic 1st Magabyte" (dd brutally the first meg) 3- Insert the SD card in your Remix Mini 4- Boom The stupid part is that I've done this in a 24 hours rush and kind of tried of backtrack what I did to make it happen... I'm not able to reproduce it but I have all the notes here: https://gist.github.com/penzoiders/582bfab2c9265716dd375fb5e7679bcf if anyone of the deveolpers is interested in this I can ship to the maintainers a couple of units (I have dozens of these used-to-be-ewaste devices). I'll attach the 1M magic boot sector. remix_mini_armbian_first_1m_pine64.bin

In the meantime I fiddled with HW crypto and PCIe sleep states. While the former is working on edge and current, the latter may be an individual error with my Samsung PM9b1 128Gb NVME SSD not working in the upper 2230 M.2 on edge. While the current 6.6 kernel does not use ASPM eventually, the edge 6.18 kernel has it and it leads to read errors. Adding pcie_aspm=off to /boot/extlinux/extlinux.conf::append helped, but I think adding a "No ASPM" to pci-quirks for this device is a better solution b/c the PCIe wifi is working (has L1 and L0s sleep). So if you like then test your NVME SSDs with the edge kernel. I'am especially interested in NVMEs reporting Capabilities L1 PM Substates with lspci -v LG // Sven-Ola

1) Language. Either I expressed myself incorrectly or I was misunderstood, but my communication on this forum will most likely proceed as follows: My message in Russian -> Translator -> My message in English And the same in reverse order. 2) A little information about me. I'm a school student, so I'm unlikely to understand any of the high-tech terms. 3) AI If it helps, here's the most productive thread of conversation with Deepseek: https://chat.deepseek.com/share/20dl6vpqy97gpu4et4 4) DTBO and DTS Thanks to AI, almost every new version of dts had a new name, but they all seemed to compile to dtbo with the same name. I'm thinking of finding one that can produce a gradient, but I haven't succeeded yet, and I haven't tried everything. I don't know what color it should be, but mine was a white-to-black gradient. I'll also attach a Python script for it. I didn't create it separately, but wrote it directly into the SSH console (as far as I understand). 5) Raspberry Pi I have a primary 32 GB SD card, which I've been using since installing Klipper on my 3D printer. I also have a spare 64 GB SD card, which I installed MainsailOS, KlipperScreen, and added printer.cfg to. Initially, when I tried using ready-made libraries, I used the primary card, and even used it for a few attempts with AI. But then I switched to a second (spare) card, so that if I messed up the firmware or made any irreparable changes, I could reinstall the OS, reset it to its original state (as mentioned at the beginning), and then repeat all the necessary operations from the beginning. It's probably best to record all your steps somewhere so that after successfully setting up the screen on the spare card, you can repeat the necessary steps on the main card. Just in case, I'll save the current config.txt and all created dts files on my PC. 6) Display I'm attaching a photo of my display and another from the product page on AliExpress. I already have it soldered into the Raspberry Pi. During my attempts, I soldered from spi1 to spi0 and back maybe five times. But I'm tired of this and want to stick with the current pinout with spi1, since I have two more accelerometers on spi0, which I desoldered while setting up the display. 7) Display nuance During the first connection, I slightly damaged the solder mask of the ground plane near the positive contact of the display with a soldering iron and shorted it out with solder. I thought something on the display was broken, so I desoldered and checked some components (the microcircuit, capacitors, and resistor), but they were intact. It was only later that I discovered the real problem. After solving the problem, I connected the 5-volt power supply, but after a couple of hours, I decided to switch it to 3.3 volts just in case. I can switch it back to 5 volts if necessary. I hope this short-circuit situation didn't affect the operation in any way. If this is helpful, I've attached all the DTS versions I currently have; they can be opened in Notepad++. When I find the one that produces the gradient, I'll edit this post or write a new one. test_display.txt ili9488-debug.dts ili9488-fixed.dtbo ili9488-fixed.dts ili9488-fixed-gpio.dts ili9488-full-init.dts ili9488-priority.dts ili9488-test.dts ili9488-test-18bit.dts ili9488-test-bgr.dts ili9488-test-reg36.dts ili9488-test-rotate.dts ili9488-working.dts ili9488-xpt2046.dts ili9488-64bit.dts ili9488-correct-horizontal.dts

A long time ago, I made an armbian guide, which included adding a kernel patch. Can you try this method? "Move them* to ~/armbian-2023.05/build/userpatches/kernel/archives/sunxi-6.1 (using the scp command or sshfs)" * would mean the cpio file (use diff3 to convert to patch file**) and any linux configuration patches needed to make your initramfs. ** diff3 linux_orig_source_folder linux_source_folder_with_cpio_file https://github.com/robertojguerra/orangepi-zero-full-setup/blob/main/README2.md#73-add-the-tv-encoder-driver-to-the-linux-kernel-source

This unit on Armbian has bigger problems than the Ethernet not coming up. such as: I believe that stems from the current U-Boot being used. If I flash mine and use my DTS that comes up correctly and the ethernet. Sorry but bringing this unit up to snuff would take more time than I'm currently willing to put in right now. If a window opens up in the future, I'll look into it.

I have a Magicsee N5 Max X4 TV box (Amlogic S905X4). Has anyone tried this with this model? I tried removing the # S905X4_Generic symbol, but it still gives an error when booting. Could you please help me? Thank you!

It is not recommended to match ZFS with vendor kernel(s). In general. Use mainline based current / edge kernels. Here v6.18.y we also might not have suitable ZFS yet as the kernel is too fresh. But if not today, it will be avail within days / weeks.

Managed to find how to solve the issue! For anyone with the same board revision (IK316Q-EMCP_V4.1) and LPDDR3 memory who is struggling to boot standard images: I tried multiple generic builds (Ophub, etc.) and DTB edits without success. The solution was using this specific pre-configured image version from the sicXnull repository. The working image is: Armbian-unofficial_24.11.0-trunk_X96q_bookworm_current_6.6.44_mate_desktop.img.xz Download Link: https://github.com/sicXnull/armbian-build/releases/download/v24.8.0-trunk.425/Armbian-unofficial_24.11.0-trunk_X96q_bookworm_current_6.6.44_mate_desktop.img.xz It booted immediately. Hope this helps others with this specific hardware.

Hello!! I am looking for help to boot Armbian on a generic TV Box sold as "MXQ Pro 4K 5G". I have tried multiple images (including official and community builds from sicXnull), but I only get a black screen or signal loss immediately after the boot attempt. Device Specifications: Model on case: MXQ Pro 4K 5G Board ID: IK316Q-EMCP_V4.1 SoC: Allwinner H313 (identified as sun50iw9p1 in Android) RAM: 1GB (Single chip configuration) Storage: 8GB eMMC Current Status: I am able to boot into the stock Android. To attempt the Armbian boot, I've tryed the Power up method, the power up pressing the hidden AV switch, using the reboot update command from a terminal emulator within Android. The issue: Upon executing the reboot command, the Android system shuts down, the display signal cuts off (or stays black), and the device never initializes Armbian (no HDMI output, no LEDs blinking differently). What I have tried:

So I tried running Armbian Minimal/IoT version with kernel 6.1 and the fan is operating normally (tested it with the stress command). I didn't realize i was working with two different kernel versions. Sometimes you just need another set of eyes to look at a problem. Thanks for the help, cheers!

If you don't have X11 or Wayland, try using the linux command "fbi" (frame buffer image). I think I put an example in this trhead or in the Banana Pi ili9341 thread (in this allwinner forum section).

Does anybody know if this will work with Allwinner H618?

Has this thread been updated yet, bro? I'm trying out Ubuntu.

Unfortunately, I have exactly the same problem.

http://blog.armbian.com/content/images/2026/01/githubhighlights-2-1.webpThis week in Armbian development saw a significant round of kernel updates, board support enhancements, and workflow improvements. Notable changes include refactoring of the sunxi patchset, multiple kernel bumps for Rockchip and sunxi platforms, and the introduction of parallel repository management. Several device-specific fixes were implemented, such as improved fan control and USB support for the Station M3, and initial support for the OrangePi 4A. Deprecated and problematic drivers were removed to streamline builds, while eBPF options and bootloader updates further enhance system capabilities. The team also addressed various patching, locale, and build issues, ensuring smoother operations across supported hardware. sunxi: refactor full patchset. by @EvilOlaf in armbian/build#9219Apply rtl8723cs bluetooth only with kernels above 6.1. by @paolosabatino in armbian/build#9184armbian-kernel: more eBPF-oriented options for userspace tooling. by @rpardini in armbian/build#9193atf: once again no-warn-rwx-segment woes. by @rpardini in armbian/build#9162Drop USB wireless driver that doesn't want to compile. by @igorpecovnik in armbian/build#9202Enable OrangePi 4A CSC Initial Support. by @juanesf in armbian/build#9185evict device trees from patches into bare dt. by @EvilOlaf in armbian/build#9215extensions/mtkflash: mtk-flash --no-erase-mmc1 landed upstream as --preserve-boot1. by @rpardini in armbian/build#9198extensions/ufs: don't check sfdisk version also when BUILDING_IMAGE!=yes. by @rpardini in armbian/build#9161feat: implement parallel repository management workflow. by @igorpecovnik in armbian/build#9224Fix broken patch due to upstream changes, drop edge kernel as its not used. by @igorpecovnik in armbian/build#9200Fix locale warnings during chroot operations. by @iav in armbian/build#9160Fix rootfs compilation (dropping deprecated gtk2 engines), drop broken patch on meson64. by @igorpecovnik in armbian/build#9199framework & kernel config - rework the optionality of kernel builtins vs modules. by @tabrisnet in armbian/build#9165framework - extension_hook_opt_out. by @tabrisnet in armbian/build#9178genio/radxa-nio-12l: OPTEE/u-boot/TF-A/FIP bootloader + EXT=mtkflash + fixes. by @rpardini in armbian/build#9159genio: kernel quality-of-life enhancements. by @rpardini in armbian/build#9167grub: remove invalid hack for hvc0. by @rpardini in armbian/build#9189Helios64: update uboot to v26-01. by @iav in armbian/build#9125host-release: allow to build on resolute. by @rpardini in armbian/build#9190mixtile-blade3: board: disable 'edge' kernel, as it's not ready for end-users yet. by @rpardini in armbian/build#9181mvebu64: re-revitalize espressobin - can build (under noble) again. by @rpardini in armbian/build#9182NanoPi R3S LTS: Update to u-boot-v2026.01. by @pyavitz in armbian/build#9207opt-out of driver_rtl8723cs in some legacy kernels so they build again. by @rpardini in armbian/build#9176patching: introduce add-only mode for DT Makefile AutoPatcher. by @rpardini in armbian/build#9204PR actions scripts: fix workflow execution name. by @igorpecovnik in armbian/build#9186rock-3a: unset BOOTFS_TYPE for non-vendor builds. by @EvilOlaf in armbian/build#9068Rockchip bump current to 6.18 and edge to 6.19. by @paolosabatino in armbian/build#9169Rockchip maint: drop upstreamed patch. by @igorpecovnik in armbian/build#9196rockchip/uefi-loong64 6.19: rewrite patches against 6.19-rc4. by @rpardini in armbian/build#9172rockchip64-6.18: Enable audio for HDMI0 on station-m3. by @kasimling in armbian/build#9170rockchip64: bump edge to 6.19; current 6.12 -> 6.18. by @EvilOlaf in armbian/build#9067rockchip64: patch ATF 2.13 to build on gcc-14+ (ref rk3399's m0). by @rpardini in armbian/build#9208rtl8723cs: stop including proprietary driver for kernel 6.19 onwards. by @paolosabatino in armbian/build#9171station-m3: Fix fan speed and enable USB 3.0 Type-A port. by @kasimling in armbian/build#9177sun55iw3.conf bump u-boot to v2026.01 (final). by @juanesf in armbian/build#9197sunxi-6.18: rename patch that does fixups for clarity. by @rpardini in armbian/build#9213sunxi: Add CONFIG_TTY_OVERY_SDIO to edge kernel config. by @EvilOlaf in armbian/build#9226sunxi: bump edge to 6.18.4. by @EvilOlaf in armbian/build#9188sunxi: bump current and edge to latest minor. by @EvilOlaf in armbian/build#9229sunxi: bump current to 6.12.64. by @EvilOlaf in armbian/build#9195sunxi: cleanup old patchsets. by @EvilOlaf in armbian/build#9212sunxi: move overlays from various patches into auto-patcher. by @EvilOlaf in armbian/build#9211thinkpad-x13s: bump arm64-sc8280xp to steev's 6.18.y. by @rpardini in armbian/build#9173tools/repository/extract-repo.sh: simplify extraction by copying directly from pool. by @igorpecovnik in armbian/build#9174u-boot: allow custom LOGLEVEL with UBOOT_LOGLEVEL (default to 6). by @rpardini in armbian/build#9191u-boot: bump u-boot to v2026.01 (final) for boards that had -rcX. by @rpardini in armbian/build#9179kernel-make: clang: Remove -Wno-error=unknown-warning-option from clang KCFLAGS.. by @iav in armbian/build#9183View the full article

I noticed the same thing. It looks like the server images might have been temporarily removed, possibly during a site update or reorganization. I’d suggest keeping an eye on the official download page or checking the Armbian GitHub mirror, they usually restore missing builds pretty quickly.

Latest nightly I found seems to work, built from source and installed klipper, etc using normal instructions online. Klipperscreen is not working but I believe I will need to build the full graphical version to get this working with my Waveshare 7" hdmi screen. Wifi and general usage of this build seems very stable. Note: I did that the lagtest ngihtly code PR for CB2 was months old, but again, it seems to work.

Been looking at getting my Helios64 back up and running after experiencing a lot of instability a few years ago. Stumbled across this thread and things look somewhat promising, but after reading through I'm unsure what I should actually do to get things running! Lots of different posts with lots of different .dtb files, seemingly PR's in to the armbian repo etc. As of today, what is the best approach to get things up and running? Do the PR's mean I should be able to just use Armbian direct from the site and have a stable NAS? EDIT: I installed the latest version listed on the Helios64 armbian page (v25.11.2 - 6.12.58-current-rockchip64) and it seems to be working fine so far.

Hello, sorry for late answer, but I had no time to experiment with my rock64 board. Maybe this issue is already resolved, if so please let me know. I'm still using kernel 6.6.63 and holding kernel packages in order not to break a working home server. So I managed to temporary switch kernel to 6.12.9 again for testing (copied old /boot and corrected symlinks) and enter UART console: Here is output of U-Boot commands you asked: Hit any key to stop autoboot: 0 => setenv b => setenv c => setenv a "a/b" => setexpr b sub "a/" "" a Unknown command 'setexpr' - try 'help' => echo ${b} => setexpr c 1 + 1 Unknown command 'setexpr' - try 'help' => echo ${c} => fdt fdt - flattened device tree utility commands Usage: fdt addr [-c] <addr> [<length>] - Set the [control] fdt location to <addr> fdt move <fdt> <newaddr> <length> - Copy the fdt to <addr> and make it active fdt resize [<extrasize>] - Resize fdt to size + padding to 4k addr + some optional <extrd fdt print <path> [<prop>] - Recursive print starting at <path> fdt list <path> [<prop>] - Print one level starting at <path> fdt get value <var> <path> <prop> - Get <property> and store in <var> fdt get name <var> <path> <index> - Get name of node <index> and store in <var> fdt get addr <var> <path> <prop> - Get start address of <property> and store in <var> fdt get size <var> <path> [<prop>] - Get size of [<property>] or num nodes and store in <var> fdt set <path> <prop> [<val>] - Set <property> [to <val>] fdt mknode <path> <node> - Create a new node after <path> fdt rm <path> [<prop>] - Delete the node or <property> fdt header - Display header info fdt bootcpu <id> - Set boot cpuid fdt memory <addr> <size> - Add/Update memory node fdt rsvmem print - Show current mem reserves fdt rsvmem add <addr> <size> - Add a mem reserve fdt rsvmem delete <index> - Delete a mem reserves fdt chosen [<start> <end>] - Add/update the /chosen branch in the tree <start>/<end> - initrd start/end addr NOTE: Dereference aliases by omitting the leading '/', e.g. fdt print ethernet0. => echo ${fdtfile} rockchip/rk3328-rock64.dtb => echo ${fdt_addr_r} 0x01f00000 => echo ${kernel_addr_r} 0x02000000 => echo ${ramdisk_addr_r} 0x04000000 => ver U-Boot 2017.09-rockchip-ayufan-1065-g95f6152134 (Apr 06 2020 - 08:10:39 +0000) aarch64-linux-gnu-gcc (Ubuntu/Linaro 7.5.0-3ubuntu1~18.04) 7.5.0 GNU ld (GNU Binutils for Ubuntu) 2.30 => CTRL-A Z for help | 1500000 8N1 | NOR | Minicom 2.10 | VT102 | Offline | ttyUSB0 I have set up rock64 to boot from SSD connected over USB3-SATA adapter (bought from pine64 store) without SD-card. To make it work I flashed latest U-Boot from ayufan to SPI by this tutorial. Maybe this error because of old U-Boot, and you're right, looks like it doesn't support setexpr command djurny, thank you for looking into this. And one question I don't understand, if I should upgrade U-Boot in SPI or I should erase SPI and wirte U-boot somewhere else? And will I be able to boot directly from USB-SSD without SD-card after that?

I don’t know about Odroid n2 but all the 2025.11 builds with graphical ui get stuck when the initial setup is completed and message appears “now booting to graphical session” and never boots 2024 builds do boot and stay normal I am using mainline uboot via spi boot.

Hi there, I also bought one (V1.5) and tried to use armbian. Unfortunately, I managed to brick it. I booted your image @johlnx from sd, that worked. Then I overwrote the internal EMMC with your image and the box won't boot anymore. Any idea how I can fix it? I made an backup of the original image, but I also read that it may be incomplete because of read protection in uboot of the emmc? I also tried to get into MaskMode by pressing the button and connecting the USB 2.0 to my Windows-PC but no device is discovered. I attached the serial uboot log. Hope somebody has a suggestion how i can boot something again. Thanks boot_with_armbian_sd_insert.log boot_without_sd_insert.log

Hello everyone! I am running Armbian in a BTV11 box (Amlogic S905X3) alongside the "meson-sm1-sei610.dtb". My cabled ethernet connection is working fine but not WIFI. No networks are found. I have already tried alternatives like meson-sm1-sei610-ethfix.dtb, that leads to my ethernet to also stop working. At first the Kernel was looking for `brcmfmac4330-sdio.seirobotics,sei610.bin` firmware, that doesnt exist in Armbian. So I made a symlink pointing to a generic `brcmfmac4330-sdio.bin`. Saw that similar fixes worked for other people. This is what I see from logs: `sudo dmesg`: [ 8.451121] brcmfmac: F1 signature read @0x18000000=0x16044330 [ 8.456690] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4330-sdio for chip BCM4330/4 [ 8.488102] usbcore: registered new interface driver brcmfmac [ 8.495653] brcmfmac mmc2:0001:1: Direct firmware load for brcm/brcmfmac4330-sdio.clm_blob failed with error -2 [ 8.858975] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available [ 8.871034] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4330/4 wl0: Oct 25 2011 19:34:12 version 5.90.125.104 [ 13.975072] brcmfmac: brcmf_sdio_readframes: read 97 bytes from channel 1 failed: -84 [ 13.979176] brcmfmac: brcmf_sdio_rxfail: abort command, terminate frame, send NAK [ 14.014920] brcmfmac: brcmf_sdio_readframes: RXHEADER FAILED: -84 [ 14.017205] brcmfmac: brcmf_sdio_rxfail: abort command, terminate frame, send NAK [ 16.618796] brcmfmac: brcmf_sdio_bus_rxctl: resumed on timeout [ 16.639467] ieee80211 phy0: brcmf_netdev_open: failed to bring up cfg80211 [ 18.506857] ieee80211 phy0: brcmf_p2p_create_p2pdev: timeout occurred [ 18.507694] ieee80211 phy0: brcmf_cfg80211_add_iface: add iface p2p-dev-wlan0 type 10 failed: err=-5 [ 22.171208] brcmfmac: brcmf_sdio_readframes: RXHEADER FAILED: -84 [ 22.171730] brcmfmac: brcmf_sdio_rxfail: abort command, terminate frame, send NAK [ 24.554983] brcmfmac: brcmf_sdio_bus_rxctl: resumed on timeout [ 24.575580] ieee80211 phy0: brcmf_run_escan: error (-110) More info available from Armbian monitor: https://paste.armbian.com/zuwididupe Does anyone have any insight that might help me figure out whats wrong with my box's WIFI?