All Activity

Thanks for your answer. I very sorry to ask you one more things please. How can I check if module is present. In modules files in "/lib/modules/6.18.10-current-meson64" ? I tried to do this : # cd /lib/modules/6.18.10-current-meson64 # grep -r "iptables" . Answer grep: ./net/ipv4/netfilter/ipt_rpfilter.ko : fichiers binaires correspondent grep: ./net/bridge/br_netfilter.ko : fichiers binaires correspondent I not an expert PS : I'am on Minimal / IOT version. Maybe it's the reason ? Thanks

logs are incomplete. dmesg is missing completely which would be the most relevant. moved to staging

https://github.com/armbian/build/blob/b8eab09ef561f2d03956098d26351d323a3b2d7b/config/kernel/linux-meson64-current.config#L355 Check your /lib/modules directory if it is present. It should be.

Why would you use an image for the Zero 3 for the 5B? You cannot simply shove an image for a random board into yours and assume it works...

This is latest edge version 6.18. Should be easily reproducible on your end, effects all rock 5B+ boards and this board is a platinum supported board.

Hi all, Over the past few months working on the A7Z, I’ve successfully ported a number of BSP drivers to Linux 6.18. The code is available here: https://github.com/alexcaoys/allwinner-bsp/tree/linux-6.18.y It’s currently tested on 6.18.19 and should, in theory, work with newer 6.18.y releases. I’ve tried to reuse as much upstream (mainline) drivers as possible, and have also upstreamed support for PCK600 and ET7304 used on the A7Z. Hopefully this helps accelerate ongoing mainline efforts. Feedback, issues, and PRs are very welcome. I may also look into creating branches for Linux 7.x in the future.

Hello. It seems there is an issue with iptables in the 6.18.10-current-meson64 kernel. I can't start Docker because of this. ``` ~# iptables -L modprobe: FATAL: Module ip_tables not found in directory /lib/modules/6.18.10-current-meson64 iptables v1.8.11 (legacy): can't initialize iptables table `filter': Table does not exist (do you need to insmod?) Perhaps iptables or your kernel needs to be upgraded. ``` As I run a docker version 28.X.X, it does not support nftable. (Cannot upgrade at the moment). What can I do to solve the problem ? Thanks

Sorry I'm not able to find the sub category for M4V2 so I chose R4S instead. But please keep in mind that this is a bug report for NanoPi M4V2. So my box has been running well for 5 years without any issue, through multiple system upgrade from armbian buster to trixie. However after I upgrade the kernel from 6.12.58 to 6.18.10 just a couple of days ago, the system started to have some weird behavior. The main symptom is that I'll lose the network connection from the box once it starts up, and it could happen after just a few minutes, or a couple of hours. I have to power cycle the box to get it back online as I don't have any peripherals, and soon I will lose the connection again. Other symptoms I've observed so far: - Once I lost the connection and powered cycle the box, the timestamp in the log looks confusing. Somehow the system clock paused at the moment when system froze. When it boots up, there could be a large gap between the NTP server and it will have to sync up, and I don't even seem to be able to find any logs before this reboot - The line `fdtfile=rockchip/rk3399-nanopi-m4v2.dtb` in `/boot/armbianEnv.txt` looks to be missing, so I added it back but it didn't fix the issue Eventually I downgraded to 6.12.58 with armbian-config, by timing the time window between the bootup and system freeze. After that the issue seems to be gone. Please find the results for `armbianmonitor -u` at https://paste.armbian.com/werujijedo For those who has the same model as mine, please think twice before upgrading. Do backup your data if you'd like to take the risk.

mar 22 2026 build. system seems to boot up, lights on, fans on at boot but no hdmi output

Pami, I have not personally found any LLM capable of generating working DTS files no matter what. It seems to be too niche for the LLM to understand. This DTS could potentially be a good starting ground for the pi, replacing "bcm2835" which refers to the pi zero 1, with "bcm2710" which refers to the pi zero 2. The github repository I linked is a good guide to getting the red displays working for a voron printer using panel-mipi driver, and I referenced it to create the DTS I use for the rock pi 4b. Also, try lowering the SPI speed to 20, 16, or 10 MHz, then raise it when you verify it works. I was frustrating myself for weeks thinking my DTS was broken, when it was fine the entire time, just my SPI speed was too high. robertoj: I appreciate your help, but I believe the issue I have with the red display (I have the same one as pami sent) is a combination of SPI commands being sent at the wrong interval (at the end of the clock cycle instead of in line), as well as insufficient SPI speed - where the display freezes above 24 MHz, and shows extreme visual tearing below it. At RGB666, its too much data for a measly 20MHz SPI rate, and the board does not support any other RGB modes in SPI. Since the TE pin is not exposed on the board, I cannot sync the SPI writes to the display. At least, that is my theory. I've given up on using an SPI display, and instead transitioned to an RGB Parallel display, which uses one gpio pin per color bit. Note that, at least in the display datasheet I received, the display actually does have the pins needed to drive it over DPI RGB Parallel. You can drive the board in 16, 18, or 24 bit mode over DPI RGB Parallel. These pins are not exposed on the board, but you could use an FPC breakout board to interface with these pins, and drive the display in DPI RGB parallel instead (accounting for the backlight voltage needed). The advantage of using RGB Parallel is it natively uses the GPU (RGB Parallel is the same technology as VGA) and has very fast refresh rate. For anyone here in future, any DPI hats that exist, like the adafruit kippah or othermod dpi topper, do not have the correct pinout to interface with this specific ili9486/8, but if you were to rearrange the pins on either the HATS or with an intermediary FPC PCB, then they would work plug and play.

Hello, i tried "Armbian_community_26.2.0-trunk.606_Radxa-cubie-a5e_trixie_edge_6.19.8_minimal.img" and wlan didn't work, i think the device tree is broken Radxa-cubie-a5e kernel 6.19.x as a quick fix, I copy the kernel 6.18.x "sun55i-a527-cubie-a5e.dtb" file to the /boot/dtb/allwinner directory to get wlan working.

@sven-ola there are 3 ways to boot the R2S: 1. Press the boot button before applying power. White USB port connected to a PC. Apply power. It goes into fastboot mode like an android. Theoretically this should let you flash the on-board eMMC. I can successfully put it in fastboot mode but the flashing has not worked. 2. Boot from eMMC 3. Boot from USB. The eMMC has two boot partitions that are fixed size and one large main partition. My project uses the u-boot environment but also does a few minor things. It prioritizes USB if it finds a bootable medium there. It also safely flashes the boot blocks on the eMMC and then the main blocks. It adds some safety checks before flashing. Nothing else.

hi, I installed in usb the last version and boot. something wrong happen here, only left these two upgrades, I tried again with backup-img and falied to boot again

Hello @lewa_j, there already is a CONFIG_POWERVR_ROGUE=y in the 6.18 kernel. This was required for Wayland and subsequently for Spacemit-GPU-Binary-Support (see https://github.com/armbian/build/pull/9515). What exactly will work additionally with this option (I am not a GPU expert)? Hello @1111Windows, doing "apt-get upgrade" on my GPU demo image this will downgrade the kernel from 6.18.18 to 6.6.99. Probably b/c recently the 6.6.99 was changed "current->legacy" and the 6.18 changed "edge->current". Also, OpiRV2 is not a really / full official Armbian image right now. So we probably need to wait until build pipelines catch up. I'll place a "apt-mark hold linux-image*" on my todo for those images. @maxsub The R2S does not have a NOR flash (or "MTD") that it boots from in the first place? That little project of yours does not look like an Armbian fork ready to be merged in. I may need some time to dig in and understand how it works. Have you considered changing the u-boot enviroment (...that can be save with "env save")?

just tested with a clean image, featuring 6.18.y and works just fine. This may be an issue if your setup is quite old, because at some point upstream changes caused Armbian kernel to break IIRC and this was worked around. The warning is persistent but doesn't actually matter. Please verify that a clean system boots normally.

hi, when upgrade I found these errors https://paste.armbian.com/utesitikah.sql what else logs do you need? var/log boot.log?

hard to tell without any logs whatsoever

hi, using rpi5, sometimes swap with rpi400, I have problem with the last upgrade, after reboot kernel does not boot, stuck in starting system. One or two of theses pkg fail. Thanks in advance

[ 5.092655] CPU1: failed to come online [ 5.092666] CPU1: failed in unknown state : 0x0 [ 10.217311] CPU2: failed to come online [ 10.217324] CPU2: failed in unknown state : 0x0 [ 15.341948] CPU3: failed to come online [ 15.341961] CPU3: failed in unknown state : 0x0 Yes we're aware of this, since it affects all H5 and H6 devices. We have a few ideas about what could be the cause like added logging (yes, sounds odd but..oh well) or certain ATF version. https://github.com/armbian/build/issues/9555

moved to off-topic since not directly related to armbian.

Hello@sven-ola After flashing the image correctly, I found that running `sudo apt upgrade` to update the system caused the kernel to fail to load; the issue appears to stem from the kernel update. Installing the `linux-image-current-spacemit 26.2.1` update causes the kernel to fail to load. I noticed that the kernel version in the image is 6.18.18-current-spacemit, while the kernel version in the Armbian repository is 6.6.99-current-spacemit. I think this is likely the root of the problem; I should not have used apt to update the kernel. In any case, thank you for porting Armbian to the OrangePi RV2.

The R2S has an internal eMMC and a USB port. After debugging the default u-boot scripts I found that it does not boot from USB once you have Armbian installed on eMMC. To reinstall a fresh copy of Armbian or any other OS, you have to use the fastboot based KyTool which does not usually work on a modern Windows PC with USB 3.0 ports. So you could end up in a state where you have to manually interrupt U-boot, or worse if you corrupt the eMMC. I rewrote the u-boot flow on the R2S. I also cleaned up the nand-sata-install and added a lot of safety checks. It will look at USB and boot from there. After that you can safely install to eMMC. Below is the link. Please let me know if it is worth submitting a PR. The changes will not touch anything in the main system, it adds these scripts to /usr/local/lib and /usr/local/sbin. https://github.com/arvindmaxar/u-boot-tools

Ok after trying a speeker switcher, switching from cinnimon to the kde version, finnally I tried flashing with the offical armbian flasher, and I tried a bunch of old online solutions that looked similar. Still my headphone doesn't work. I think it is due to armbian thinking the built in sound card is the headphones. But on a positive note the weird unmounting of armbian when my chromebook sleeps or when the lid is closed does not occur on armbian kde. So far kde is more stable than cinnimon.

Hello @sven-ola, big thank you for all you work on RV2 support! I was wondering, is it possible to enable CONFIG_DRM_POWERVR for 6.18 and up? I guess more than that is required to actually use it though.

@José Manuel Márquez Luque try these images https://github.com/NickAlilovic/build/releases/tag/20250306