Active threads

Armbian current: It seems that the N2+ is [i]immune[/i] to Chrony and systemd-timesyncd. The only way I can set the date/time is manually through date -s. # systemctl status systemd-timesyncd ● systemd-timesyncd.service - Network Time Synchronization Loaded: loaded (/usr/lib/systemd/system/systemd-timesyncd.service; enabled; preset: enabled) Active: active (running) since Mon 2025-11-24 13:06:59 PST; 31min ago Invocation: 50da85c1116348dbbd83cca270da6ff8 Docs: man:systemd-timesyncd.service(8) Main PID: 1185 (systemd-timesyn) Status: "Idle." Tasks: 2 (limit: 4227) Memory: 1.6M (peak: 2.3M) CPU: 79ms CGroup: /system.slice/systemd-timesyncd.service └─1185 /usr/lib/systemd/systemd-timesyncd Nov 24 13:06:59 lab systemd-timesyncd[1185]: System clock time advanced to recorded timestamp: Mon 2025-11-24 13:06:59 PST Nov 24 13:06:57 lab systemd-timesyncd[1185]: Network configuration changed, trying to establish connection. Nov 24 13:06:57 lab systemd-timesyncd[1185]: Network configuration changed, trying to establish connection. Nov 24 13:06:57 lab systemd-timesyncd[1185]: Network configuration changed, trying to establish connection. Nov 24 13:07:01 lab systemd-timesyncd[1185]: Network configuration changed, trying to establish connection. Nov 24 13:07:11 lab systemd-timesyncd[1185]: Timed out waiting for reply from 10.2.1.10:123 (10.2.1.10). No, the network configuration has na-ha-hot, changed, Spastic. I see via tcpdump, the request going out 123/udp and the response, coming back. The information arrives at the destination. But it hits a hard rock head and disintegrates. Of course if it can't set the system clock, there's no sense trying to make it set the RTC. How is this possible in the 21st Century? Does time, no longer matter to Gen Z? Is this the precursor to the Apocalypse? Should I convert to religion and start praying?

If you are using the radxa-pkg github "which is the most up-to-date" know that its hardcoded to point to specific firmware. To get around this you need to create a file: This example is for an SDIO variant using the radxa dkms package cat > /etc/modprobe.d/aic8800-wireless.conf <<- EOT options aic8800_fdrv_sdio aicwf_dbg_level=0 custregd=0 ps_on=0 options aic8800_bsp_sdio aic_fw_path=/lib/firmware/aic8800_fw/SDIO/aic8800 EOT Also note that the AIC8800 firmware located in armbian-firmware is kind of old and probs not compat with the radxa builds.

Scroll back and read all my posts from April 11 onwards (page 17). On Radxa's github there are Wifi/BT drivers for AIC8800. They are at version 4 now : https://github.com/radxa-pkg/aic8800/releases/tag/4.0%2Bgit20250410.b99ca8b6-3 Also to fix BT : sudo crontab -e then add the line : @reboot sudo hciattach -s 1500000 /dev/ttyS1 any 1500000 flow nosleep then reboot the H96.

We are slowly releasing v25.11 images and here I did some mess-up, fixed now. We don't offer Bookworm anymore, so Trixie it is. If you need to Bookworm for some reason, you can build on your own or use the one from archive: http://archive.armbian.com/ Attached torrent will download super fast. Armbian_25.11.1_Helios64_trixie_current_6.12.58_minimal.img.xz.torrent

Will it work on the H96 max RK3528 4gb ram 64gb rom?

Hi @BipBip1981, thank you for sharing your thoughts. It is positive to hear from people still running these, much appreciated!

Im trying to flash armbian into the eMMC but its not detected, only the SD card. What should i do? Useful info: CPU/Chip/Idk: sun8iw7p1 PCB Model(?): H3 Q44 V4.0 Uname -a: Linux orangepipcplus 6.12.58-current-sunxi #1 SMP Thu Nov 13 20:34:41 UTC 2025 armv7l GNU/Linux dmesg | grep -i mmc [ 0.000000] Kernel command line: root=UUID=cf60c629-17b3-4fb8-91bb-24bd021f8c6b rootwait rootfstype=ext4 splash=verbose console=ttyS0,115200 console=tty1 hdmi.audio=EDID:0 disp.screen0_output_mode=1920x1080p60 consoleblank=0 loglevel=1 ubootpart=def8ba6d-01 ubootsource=mmc usb-storage.quirks=0x2537:0x1066:u,0x2537:0x1068:u sunxi_ve_mem_reserve=0 sunxi_g2d_mem_reserve=0 sunxi_fb_mem_reserve=16 cgroup_enable=memory [ 0.000000] Unknown kernel command line parameters "splash=verbose ubootpart=def8ba6d-01 ubootsource=mmc sunxi_ve_mem_reserve=0 sunxi_g2d_mem_reserve=0 sunxi_fb_mem_reserve=16 cgroup_enable=memory", will be passed to user space. [ 4.995824] sunxi-mmc 1c0f000.mmc: Got CD GPIO [ 5.019105] sunxi-mmc 1c0f000.mmc: initialized, max. request size: 16384 KB [ 5.031030] sunxi-mmc 1c11000.mmc: initialized, max. request size: 16384 KB [ 5.048053] mmc2: Failed to initialize a non-removable card [ 5.063249] mmc0: host does not support reading read-only switch, assuming write-enable [ 5.067129] mmc0: new high speed SDXC card at address aaaa [ 5.071189] mmcblk0: mmc0:aaaa SC64G 59.5 GiB [ 5.080563] mmcblk0: p1 [ 5.316321] ubootsource=mmc [ 7.603641] sunxi-mmc 1c10000.mmc: allocated mmc-pwrseq [ 7.635175] sunxi-mmc 1c10000.mmc: initialized, max. request size: 16384 KB [ 7.687081] mmc1: new high speed SDIO card at address 0001 [ 8.364751] EXT4-fs (mmcblk0p1): mounted filesystem cf60c629-17b3-4fb8-91bb-24bd021f8c6b ro with writeback data mode. Quota mode: none. [ 14.091111] EXT4-fs (mmcblk0p1): re-mounted cf60c629-17b3-4fb8-91bb-24bd021f8c6b r/w. dmesg | grep -i mmc2 [ 5.048053] mmc2: Failed to initialize a non-removable card I also extracted a DTB file and DTS file from the android of the TV box, if that is useful (I used AI for that, and dont really know if they are useful) Thanks. dts.txt

I found this thread https://forum.armbian.com/topic/47929-banana-pi-bpi-m2-ultra-with-armbian-stops-load-after-scanning-for-btrfs-filesystems/

I recently updated my Orange-Pi-PC2 to Debian 13 (trixie). Image: "Armbian_community_26.2.0-trunk.7_Orangepipc2_trixie_current_6.12.58_minimal.img.xz". Everything works now, and the issue mentioned above no longer exists! Maybe it will be useful to someone... However, I still had to make some adjustments to "/boot/dtb/allwinner/sun50i-h5-orangepi-pc2.dtb" sun50i-h5-orangepi-pc2.dtb: Overclocked the processor to 1.44 GHz (new board revision 1.368 GHz CPU!); Similar to the other firmware versions, I configured the red LED as a power indicator (constantly lit) and the green LED as a heartbeat indicator. For everything to work, you also need to correct the parameter MAX_SPEED=1440000 in the file "/etc/default/cpufrequtils" cpufrequtils.

No need to recompile, rk322x already have had all the right bits in the right place for years. Everything is written down in the first page of the thread for rk332x tv boxes (What works: ---> Hardware video acceleration) in the hope people read it.

Good that you posted serial console output. A bit more and text (starting at power on when U-Boot starts) would be clearer, but I think the 2 top lines with 'Android' mentioned already indicate what is wrong I think; ROCK3C has SPI-flash where also the bootloader (U-Boot usually) can be stored and this has priority over SD-card bootloader. So it seems older/incompatible Android U-Boot variant in the SPI-flash loads Linux and as you use mainline Linux kernel, this won't work correctly as you see. On my ROCK3A, almost similar SoC I get all sorts of strange crashes/hangs in that situation. So use MaskROM mode to wipe SPI-flash or write a correct U-Boot version to it; see https://docs.radxa.com/en/rock3/rock3c/low-level-dev/3c-maskrom?host_os=Linux_MacOS Other option maybe is to boot with an image that has vendor kernel (I use 6.1.115 on my ROCK3A with legacy U-Boot) so then the board can be operated via serial console and from there write the SPI-flash with dd or flashcp (see /dev/mtd*).

Thank you @KhanhDTP. I think I have a pretty good handle on how (and your post on that thread was in particular very helpful, thank you). It looks like a lot of people here are desktop optimized. My plan is headless, so expectation is 25.11.1 / 6.1 and libMali route but with RKNN (XFCE only for occasional desktop, Gnome is too hungry, XFCE + X11 + software rendering is fine on rare occasions I'd need it). I think the question I was trying to ask is more along the lines of understanding what to expect for the default, and if it made sense to enable one of the drivers by default, but I'm realizing there are proprietary dependencies and enough obscure use cases that this gets more challenging. Thanks to everyone for all of the thoughts, hard to imagine navigating all of this without your contributions.

Noble image didn't boot on Orange pi 4A

I have a unit that I am unable to boot from SD card as it has no such physical device. Using a terminal emulator in Android I can see partitions being loaded, and have managed to get several "partitions" (mmcblk01p01 to p20) copied off to a flash drive. These turn out to be data files, so I can't load/modify them on a VM. I had hoped to find the boot.scr/boot.cmd file and modify it to force it to mount from USB in the first instance. The unit has 2 USB ports. There is a push switch that I had to unglue. It runs Android when pushed in, and I get a black screen when it is in the OUT position, so I'm assuming that the OUT position puts the unit into USB burning mode, or whatever. I have ordered UART header pins and adapter so will be able to do more research once those are in place. From your analysis above, can you recommend a way of forcing a boot from USB using the UART serial interface (I don't see a recover-from-usb U-Boot command)? I have an armbian s905x image all ready to go. Ideal situation would be that I get the Armbian running from USB then flash the eMMC. Any help gratefully received, Best, John

Armbian provides vanilla Debian (or Ubuntu) Cinnamon. In general, touch to the user-space part is minimal, so you are running plain Debian Cinnamon desktop, more or less. And as packages comes from there, bugs follow. Armbian team don't have resources for dealing with desktop. Minor problems only. And as it was already mentioned Exactly. I saw this (recently introduced) problem but since I have absolutely no idea where to look, I removed Cinnamon images from upcoming release. We don't touch Cinnamon nor other desktops beyond installing wallpaper. Probably tasksel installed variant will likely be broken too.

I've successfully booted Armbian from USB following the tutorial above, and I've managed to write Armbian from the USB drive to the eMMC. Now I want to create an Armbian firmware that can be directly flashed to the H96 M9/S eMMC using RKDevTool.exe, but I'm not very smart - even simple things take me a very long time to figure out. If any of you have this, please share it. If I manage to figure it out, I'll also share my findings.

afaik wayland is not supported in this version of xfce. You have to use Gnome or KDE.

What do you expect from single lane M.2 PCIe2.0?

I never said it was a Debian issue (you failed to mention which userspace you were running in your original post, btw). The issue is with whereever you got your authelia package from (which you also failed to mention). You also failed to mention what error exactly you are running into. But yes, you are right, Debian will and can do nothing about it. Basically the same is true for Armbian, the symlink is there for a reason and there to stay. You are in the wrong place to get this fixed.

If you already checked "dmesg|grep panel-mipi" and "dmesg|grep spi", check this: * share which LCD you are using. Half of those LCDs are waveshare clones, which need a different driver. My DTS works in the RED LCDs. * Look at the uboot messages in the serial port output. Does it confirm it is finding your dtbo and using it? * verify that panel-mipi-dbi.ko exists in the modules folder. I know it is not preselected by default within the linux configuration menu * Search the word "pinctrl" in this thread https://forum.armbian.com/topic/44191-orangepi-zero-lts-ili9341-tft-lcd-and-later-orangepi-zero-3/#comment-204741 To confirm that the kernel driver is using the gpio and spi pins * send link of the rock3c DTS you are referencing, to see an example of how GPIOs are configured * correct the gpio pin map you shared. Instead of tx/rx, use MOSI, MISO. Highlight and label clearly the CS0, CS1, RESET, DC, IRQ * explain how those gpio numbers gpioX,XX transform into the DTS gpioX XX 1/0 If you at least get noise in the LCD, you are 50% done (and maybe you will get lucky in the last 50%)

LE Audio introduces a modern, low-power, low-latency Bluetooth® audio architecture that overcomes the limitations of classic Bluetooth® profiles. Get a detailed look at its features, how its supported on Linux, and what lies ahead. View the full article

The schematic propose a 10kohms as NC, that may be an acceptable value. With an barrel plug 5V/3A, I think the laptop should be able to powerup without battery.

As far as I can tell, Armbian does not support the OrangePi RV2. Where did you get the image from? Or are you really talking about the PC2? RISC or ARM? Big difference.

Yes, but packages hasn't been pushed out yet. We need to test and possibly fix last problems on images. In 10-14 days.

Thank you Avenom! I've paused my project. I'm even undecided about continuing to use the Orange Pi Zero 2W. As soon as I find a little more patience, I'll try your suggestion. Thanks again for your post.