All Activity

Cinnamon desktop environment is bugged for me, both my a95x r2 (amlogic s905w) and a95x f3 slim (amlogic s905x3) showing no display, blank screen like no input after loging in. My suggestion for desktop ubuntu based varian, better change it to Mate desktop. The armbian desktop cinnamon varian based on ubuntu is now work for me after switching to mate desktop

can this SoC boot from a USB drive? i've tried it multiple times and it didnt work.

moved to staging

Orange Pi 5 pro,whith Armbian_community_26.2.0-trunk.7_Orangepi5pro_noble_vendor_6.1.115_gnome_desktop 。 when I try to start Eclipse/idea/vscode or other JavaApp , java processes crash and gets core dump every time, tested on Jdk 17,21 25 ,both openjdk and oracleJDK。 It seems there is a compatibility issue between the kernel and the JDK. How can I fix it? Or I have to wait kenel update? some error like Current thread (0x0000ffffa802b9b0): JavaThread "main" [_thread_in_vm, id=6202, stack(0x0000ffffaeb62000,0x0000ffffaed60000) (2040K)] Stack: [0x0000ffffaeb62000,0x0000ffffaed60000], sp=0x0000ffffaed5ce40, free space=2027k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0xddc444] Symbol::as_C_string() const+0x14 V [libjvm.so+0xbef608] Method::print_external_name(outputStream*, Klass*, Symbol*, Symbol*)+0x40 V [libjvm.so+0xb07e7c] LinkResolver::resolve_method(LinkInfo const&, Bytecodes::Code, JavaThread*)+0x154 V [libjvm.so+0xb0a85c] LinkResolver::linktime_resolve_virtual_method(LinkInfo const&, JavaThread*)+0x3c V [libjvm.so+0xb0b204] LinkResolver::resolve_virtual_call(CallInfo&, Handle, Klass*, LinkInfo const&, bool, JavaThread*)+0x3c V [libjvm.so+0xb0b3a0] LinkResolver::resolve_invokevirtual(CallInfo&, Handle, constantPoolHandle const&, int, JavaThread*)+0xd4 V [libjvm.so+0x887cd4] InterpreterRuntime::resolve_invoke(JavaThread*, Bytecodes::Code)+0x250 V [libjvm.so+0x887f80] InterpreterRuntime::resolve_from_cache(JavaThread*, Bytecodes::Code)+0x3c j java.util.AbstractSet.removeAll(Ljava/util/Collection;)Z+8 java.base@25.0.1 j org.eclipse.osgi.container.ModuleResolver$ResolveProcess.resolveRevisions(Ljava/util/List;ZLorg/eclipse/osgi/container/ModuleResolver$ResolveProcess$ResolveLogger;Ljava/util/Map;)V+424 j org.eclipse.osgi.container.ModuleResolver$ResolveProcess.resolveRevisionsInBatch(Ljava/util/Collection;ZLorg/eclipse/osgi/container/ModuleResolver$ResolveProcess$ResolveLogger;Ljava/util/Map;)V+253 j org.eclipse.osgi.container.ModuleResolver$ResolveProcess.resolve()Lorg/eclipse/osgi/container/ModuleResolutionReport;+307 j org.eclipse.osgi.container.ModuleResolver.resolveDelta(Ljava/util/Collection;ZLjava/util/Collection;Ljava/util/Map;Lorg/eclipse/osgi/container/ModuleDatabase;)Lorg/eclipse/osgi/container/ModuleResolutionReport;+19 j org.eclipse.osgi.container.ModuleContainer.resolveAndApply(Ljava/util/Collection;ZZLorg/eclipse/osgi/container/ModuleContainer$ResolutionLock$Permits;)Lorg/eclipse/osgi/report/resolution/ResolutionReport;+256 j org.eclipse.osgi.container.ModuleContainer.resolve(Ljava/util/Collection;ZZ)Lorg/eclipse/osgi/report/resolution/ResolutionReport;+63 j org.eclipse.osgi.container.ModuleContainer.refresh(Ljava/util/Collection;)Lorg/eclipse/osgi/report/resolution/ResolutionReport;+34 j org.eclipse.osgi.storage.Storage.checkSystemBundle([Ljava/lang/String;)V+242 j org.eclipse.osgi.storage.Storage.createStorage(Lorg/eclipse/osgi/internal/framework/EquinoxContainer;)Lorg/eclipse/osgi/storage/Storage;+17 j org.eclipse.osgi.internal.framework.EquinoxContainer.<init>(Ljava/util/Map;Lorg/osgi/framework/connect/ModuleConnector;)V+146 j org.eclipse.osgi.launch.Equinox.<init>(Ljava/util/Map;Lorg/osgi/framework/connect/ModuleConnector;)V+10 j org.eclipse.osgi.launch.Equinox.<init>(Ljava/util/Map;)V+3

Good day, @jock the link of the Multitool is not valid anymore. Please help where I can download from? Thank you for your efford.

I also tried the latest image (https://github.com/armbian/community/releases/download/26.2.0-trunk.22/Armbian_community_26.2.0-trunk.22_Rock-3c_trixie_current_6.12.59_minimal.img.xz) and it works fine (with mainline u-boot). I think I may have experienced problems using radxa's software to erase the spi flash memory, but writing an image fine would always work. So you may be better off writing Radxa's u-boot image to the spi flash memory, as per their instructions (and to get rid of the Android image). You can subsequently manage the spi flash memory either directly from u-boot (by interrupting start-up) or from the linux terminal. See comments by @amazingfate in this post for instruction on how to write Armbian u-boot image to mtdblock0 from a linux terminal.

I went out and bought a waveshare clone 3.5 inch display, to try and confirm I haven't spent the last few weeks trying to do the impossible with broken GPIO pins or something - and got a partial success eventually, using fbtft, displaying basic console and plymouth boot logs. It has poor fps like you said - which I expected, its the reason I tried to use the tiny DRM driver from the beginning, but now I know the rockpi and DTS is functional. The same DTS also shows a broken, purple / blue output of bars on my red ili9488 display only if I adjust the bus width to 16 instead of 8 (0x10, instead of 0x08), otherwise it remains a blank white screen. A bus width of 18 and 24 also only gave me a white screen, so 16 might be correct. I've been unable to confirm touch works, since I only have a basic console and I can't figure out how to start LXDE on a framebuffer device, but I do see messages insinuating it initializes under dmesg | grep spi. I could probably just query the GPIO interrupt to find out if touch is working. Not that important right now. I did realize that the big "fixups" section at the bottom is clearly used to replace the empty 0xfffffff targets throughout. I'm unsure why the DTS was written this way, but it works so I am not going to touch it (changing the targets and switching from hex to decimal values broke the DTS for some reason.) Unfortunately, a simple drop in replacement of fb_ili9486 with panel_mipi_dbi did not make either display work, even with the added arguments you use in your latest DTS. Clearly I have much more work to do. BUT I've finally confirmed the DTS works, and all GPIO is claimed and SPI is initialized for both displays (even if the red LCD is showing gibberish), so now I need to nail down the subtle differences with the displays like the bus and reg width and find the right combo of spi clock speed, reg bus widths, and buffer length to get it all to work with fbtft (if only aliexpress sellers put up datasheets or example code!). Then I can follow the second half of your journey to hopefully translate a working fbtft setup to a panel_mipi_dbi setup. Maybe get backlight PWM working. All this still on edge kernel 6.18, on a rockpi 4b plus.

I have the NanoPi-R6C and that came out of the box with an OpenWRT variant on eMMC. Indeed many partitions, but I think I managed to get it running somehow with Debian/Armbian rootfs on some higher partition number, I don't remember exactly. As long it can load boot.scr. Indeed eMMC is number 2, I guess they avoid potential confusion that is sometimes there with SBCs and various OSses swapping numbers for SD-card and eMMC. I had that once, no data loss but costed a lot of time. It is a bit similar to that on 6-SATA PC's, Debian might name the OS dev (SSD) /dev/sdb and a large HDD /dev/sda while Opensuse names OS always /dev/sda. So what do we do with 2-MMC SBC's ? I see my HP x86-64 dualrole computer/tablet uses /dev/mmcblk1 (its eMMC) for OS (Linuxes at least, Windows10 I don't remenber). The SD-card slot I have normally empty but uses /dev/mmcblk0 if card is inserted. It has UEFI and SecureBoot and TPM, so no choice actually like there is with opensource U-Boot. For NanoPi-R6C I have written Tianocore EDK2-UEFI to eMMC and appears as /dev/mmcblk1. I do not use the rest of the 32GB storage, but the UEFI binary comes with 1 partition, so easy to use the rest of the 32GB, but currently I need the much larger and faster NVME. And for emergency, if I insert an SD-card with newly generated rolling/edge image or so, it boots from that and is then /dev/mmcblk0. So this is IMO the preferred numbering, but I already had created some shell script code that can identify the boot partition and the root partition, but it is not too generic, only works if certain mounts are there which is what I have as I focus on EFI bootable and Btrfs with subvolumes ('nested' and default). So I would at least use 0 for SD. 1 for eMMC is fine. For the LEDs, on my NanoPi-R6C, I actually don't know, I never look at them. I think it is not correct with my installation (in-place upgraded and also other Linuxes), but I guess correct with current downloadable images. At least they were correct with the FriendlyElec OpenWRT that was pre-installed. I still can't get maskROM mode to work, so I am a bit paranoid on messing too much with data in the Rockchip loader area. I am not sure what happens if I put rubbish data or broken U-Boot there, can I still start from SD-card is the question. I might need to apply a fixed voltage between 9-20V as powersupply, but need to look in PCB schematics again first. For the Zero2, I see removable eMMC, so no risk or fear for 'hard-bricking'. Although I would check if maskROM works. For network, I assume it is the on-SoC port, so fixed off-the-shelf, so end0 is fine. For optional WLAN, I am not sure, likely some PCIe/HWtree named string, I have seen multiple altnames for 'wlo1', at least 'wlp1s0' or 'wlx<MACaddress>'. systemd-networkd should be able to handle those, NM can do all anyway.

Hi everyone, how's it going? I'm new to the forum and I'm having trouble getting my Chinese T95 mini TV box to run Linux. I want to switch it to a basic server, but I'm having problems booting it from the SD card. I'm using the sunxi-fel mode method in Linux. I tested Armbian_23.8.1_Orangepipc_jammy_current_6.1.47_minimal.img and others like Armbian_23.8.1_Orangepipc_jammy_current_6.1.47.img. I used the .bin file generated on this forum. Boot it using the method `sudo sunxi-fel -v -p uboot u-boot-sunxi-with-spl.bin` in the terminal. TV BOX Model: T95mini | R69 - EMCP V2.0 - H3 Allwinner. The screenshots below show the screen freezing. I'm a total noob, guys, if you could please explain the procedures, indicate what needs to be done to make it work. Thanks in advance libretech_all_h3_cc_h3_mem_336 - u-boot-sunxi-with-spl.bin

Hi everyone, wanted to share what we found attempting Armbian support for Zero2. Zero2 utilises an Android-style partition layout from FriendlyElec, which I found to be fundamentally incompatible with Armbian's partition scheme. It seems to use an Android layout (boot at partition 4, rootfs at partition 8, etc.) vs Armbian's standard GPT layout. U-Boot is configured to look for partitions at specific Android-style locations Zero2 assigns SD=mmcblk0, eMMC=mmcblk2 (opposite of typical RK3528 boards) What I think is needed: Adapt hinlink_rk3528_defconfig for Android partition layout Modify partition table generation in the Armbian build system Update bootloader scripts to match partition locations Handle the inverted mmcblk device assignments LED mapping adjustments (Zero2 uses 2-LED system: sys_led, user_led vs typical 3-LED RK3528 boards) Network interface detection (single ethernet vs dual on R3S/hinlink) The device tree is already merged (rk3528-nanopi-zero2.dtb - thanks Jonas!), so that part is straightforward. It's specifically the bootloader/partition integration that's the blocker. Would love to hear thoughts. For now as a workaround, we've stayed with FriendlyElec's Ubuntu base to keep our project moving.

Glad I fell on this post Igor, Thank you for the share.. (download was indeed really fast!) I managed to install without any issues. (been using buster for way too long) Cheers, Again thanks in advance!

I already see what the issue is: I have configured things in such a way that strange/new machines get served differently then known/existing ones. In addition, the known/existing ones need an extra setting in case of systemd-resolved. This makes a quick test with some random VM like this appear doing things wrong, but is actually expected. If I purge --autoremove netplan.io and put a symlink ln -sf /usr/lib/systemd/network/89-ethernet.network.example /etc/systemd/network/89-ethernet.network, there is working network again after reboot or restart service.

Same trick as in but with N2+ image sha256sum: 5627794e883fc3b8b9ccf918efe4e5427621761402e8e2d10b05730495fc19ce Armbian_25.11.1_Odroidn2_trixie_current_6.12.58_minimal.i mg.xz and 1 reboot, then with armbian-config set my timezone to CET and reboot again: root@odroidn2:~# timedatectl Local time: Fri 2025-11-28 19:50:36 CET Universal time: Fri 2025-11-28 18:50:36 UTC RTC time: Fri 2025-11-28 18:59:21 Time zone: Europe/Amsterdam (CET, +0100) System clock synchronized: no NTP service: active RTC in local TZ: no root@odroidn2:~# timedatectl Local time: Fri 2025-11-28 20:00:31 CET Universal time: Fri 2025-11-28 19:00:31 UTC RTC time: Fri 2025-11-28 19:00:32 Time zone: Europe/Amsterdam (CET, +0100) System clock synchronized: yes NTP service: active RTC in local TZ: no It seems it took several seconds for a sync, but nothing strange I think. However, important notice is that networking has picked the wrong DNS server; It seems to assume 'router IP = DNS IP' which is not the case in my case, so several things fail, especially in-house things, not what goes outside. This is not the case when network-manager+openresolv do the network config (and no netplan.io). I run 2 computers with systemd-networkd+systemd-resolved, but that took a lot of time and reading and some config tweaking before those do simply the same as before with network-manager+openresolv. And no benefit, only that they can run slightly easier as container with own MAC-address (real HW must be off then of course) and also a bit easier as container host.

Seems you are using redhat kernel. it means something wrong changed in armbian meson64 kernel config after 6.16.??

Thanks for confirming. That makes 6.18 look very compelling. I have some ideas for how I'd like to present this and I'm finding myself wanting to flesh out my overview... If anyone has preferences for a better place than my PR comment to publish please let me know.

Looks like it's working fine! Thanks for your work.

@zmxyz I added support for A7Z. But I haven't tested it yet. I don't own a A7Z. Compile an image and let me know if it works.

@ARx8 @rafaeldavid I was having this problem, and I just figured out that this is a cheat from the chip. I don't know the details but basically they mark the memory as 2GB but it actually just have 512MB. The Armbian sees 2GB but when you do a task that requires more that the actual 512MB it crashes. To solve that I manually set the memory on the Armbian to be 512MB. Edit the file: /boot/armbianEnv.txt Add the line (or change if already exists): extraargs=mem=512M On my case the device claimed 2GB of Ram. I reach the 512M testing. To get to this number I ran: free -h This gave me the amount of memory the system was already using (230M). After that I apt installed memtester and start testing the memory: memtester 200M I started at 200M and cancel the test (CTRL-C) on the firsts interaction after: Stuck Address : ok Random Value : ok Compare XOR : ok Compare SUB : ok Compare MUL : ok Compare DIV : ok Compare OR : ok Compare AND : ok The other tests took too long and if the problem is the memory that didnt exist just the firsts test would be enough. I ran memtester increading by 50M, so 200,250,300... And on 300 the system crashed, so I assumed the real memory of the chip was 512 (the 230 from the system + the 250 from the memtester before it crashed).

I saw a commit for the A7Z (not the A7A, the one that looks like the Raspberry Pi Zero). Is it available now?

FYI: I got the trunk.22 image booted, running, configured and rebooted in a CLI based QEMU KVM on my NanoPi-R6C running Trixie with edge 6.18.0-rc kernel. xzcat Armbian_community_26.2.0-trunk.22_Rock-3c_trixie_current_6.12.59_minimal.img.xz > armimg.img mkdir -p 1 ; losetup -fP --show armimg.img ; mount /dev/loop0p1 1 cat boot.cmd.qemu-rock3-ext4 load virtio 0:1 ${ramdisk_addr_r} /uInitrd load virtio 0:1 ${kernel_addr_r} /Image fdt addr ${fdt_addr} setenv verbosity "7" setenv rootfstype "ext4" setenv rootdev "LABEL=armbi_root" setenv bootargs "root=${rootdev} rootwait rootfstype=${rootfstype} loglevel=${verbosity}" booti ${kernel_addr_r} ${ramdisk_addr_r} ${fdt_addr} mv ./1/boot.scr ./1/boot.scr.rock3c_bak mkimage -C none -A arm -T script -d ./boot.cmd.qemu-rock3-ext4 ./1/boot.scr sync umount 1 ; losetup -d loop0 ln -sf /usr/lib/u-boot/qemu_arm64/u-boot.bin . taskset --cpu-list 0-3 qemu-system-aarch64 -M virt -cpu host -enable-kvm -m 2048 -smp 4 \ -bios u-boot.bin \ -drive if=none,file=armimg.img,format=raw,id=hd0 \ -device virtio-blk-device,drive=hd0 \ -netdev bridge,id=hn1 -device virtio-net,netdev=hn1 \ -nographic It is a quick and dirty modification from something I did a year ago for ROCK3A to test single partition btrfs formatted rootfs (custom compiled U-Boot), so I am not 100% sure if all is correct, but it works. So the trunk.22 image seems to be fine, except that I needed own boot.cmd. I could not get the one in the image to work. At least it showed something like 'failed to load /armbianEnv.txt'; that might be a U-Boot version/variant issue, it is of course not the blob for the rock3c in the image between MBR and bootFAT but a generic Debian Trixie for qemu (U-Boot 2025.01-3 (Apr 08 2025 - 23:07:41 +0000)).

No. This fork uses the name Armbian without permission and they do not contribute to the core development process. Instead they trick you into thinking that you'd get any sort of support here at our place whatsoever.

I didn't know it wasn't the original. But even if it's a fork, maybe you can still help based on the original... amlogic-s9xxx-armbian

Hello fedes_gl, thx for testing. Regarding wifi I got the same error with connectet LAN cable because the default Gateway is pointed to LAN address. Remove the LAN cable and you should be able to connect over wifi. x88pro:~:# routel Dst Gateway Prefsrc Protocol Scope Dev Table default 192.168.178.1 192.168.178.71 dhcp wlan0 192.168.178.0/24 192.168.178.71 kernel link wlan0 127.0.0.0/8 127.0.0.1 kernel host lo local 127.0.0.1 127.0.0.1 kernel host lo local 127.255.255.255 127.0.0.1 kernel link lo local 192.168.178.71 192.168.178.71 kernel host wlan0 local 192.168.178.255 192.168.178.71 kernel link wlan0 local

Note that ROCK3A images are 2 partitions, so 1st is boot and FAT formatted, so you should change verbosity to 7 in armbianEnv.txt, then the log will also contain kernel logs, that might tell what the problem is.

I now realize there is no ROCK3C downloadable image on the Armbian homepage as I was going to suggest you to download a 25.8.x image or so. So '26.2.0-trunk.7' is alpha or beta release and that changes per day, now it is .22 I see. You need enough tools and skills and time to get such a community level support SBC running. The images are just generated, you are the tester/checker. I can't really help you as I don't have a ROCK3C and that is definitely needed for such a case. I like the ROCK3C because with a SATA breakout board added, it is a good and cheap replacement for an old x86 PC to drive a SATA HDD/SSD. But the SATA breakout board can only be bought in China and I am in EU. Checking earlier downloaded schematic: No higher input voltage than 5V. Amount of Watts consumed does not say anything about voltage level and or short dips, so it is certainly no 100% proof that power is not a or the problem, but up to yourself to judge. Also the Rx serial path (so ROCK3C signal reception) might fail. As you mention USB keyboard it reacts. I think standard ethernet will be online, so that is another way to control the board, but needs the image manually pre-configured. You can check in your router for hints. You can build image yourself or use Radxa image, it has KDE Bookworm. You then can merge upgrade that yourself, but as indicated, it is DIY. Also ARM SBC images use 1 kernel only traditionally and you cannot select at boot time. I first changed Armbian boot method to use extlinux instead of boot.scr, so now I can select at least another kernel. If hadn't done that the board would be gathering dust now for a year already. I only used maskROM once just to see if it worked, with CLI tool rkdeveloptool (is default available in Opensuse Tumbleweed, I do not use Windows).