All Activity

No and we can't get new one as it doesn't exists. Common practice is that vendor drops driver sources to the wild and never look back. All costs of maintenance are on few people in and around this community. This chip is probably only used by few (Orangepi) single board computers and perhaps some Android tablets, TV boxes. Which are not in our focus anyway. There is some community efforts to bring this to mainline, but I doubt this chip will find a way there. Check here https://github.com/torvalds/linux/tree/master/drivers/net/wireless/realtek if there is any sign of it.

This method will keep working for years and I will try to fix problems as long as they won't take too much time. Most of Armbian images doesn't have boot partition as it is not needed. Most of boards does not support boot from flash drive, but from SD card. I have absolutely no clue. There is a whole section of Armbian community forums that are dealing with the complexity of booting weird TV box hardware. I suggest you to start here: https://forum.armbian.com/forum/189-faq/ It is enough that board uses different memory modules and device won't give any sign of life. When you manage to boot Armbian Bookworm with help from TV box section, use armbian-config.

In the meantime I was able to compile a customized armbian image with the Designware I2C driver enabled. This solved the problem for me ... until a kernel update was installed via apt. This made my DSI display unusable again. What I did: I used the official buildsystem from https://github.com/armbian/build. In the kernel config menu, I selected "Device Drivers / I2C support / I2C Hardware Bus support / Synopsis DesignWare I2C adapter" to be included as a module ("<M>"). This led to the line "CONFIG_I2C_DESIGNWARE_CORE=m" being present in the kernel configurafion file 'linux-bcm2711-current.config'. Finally I recieved the working armbian image with the modules 'i2c-designware-core.ko' and 'i2s-designware-platform.ko' being present under /usr/lib/modules/... To be able to perform kernel updates in the future, it would really be helpful to have the drivers already in the official armbian builds. What can I do to improve the situation? I came here to seek the 'standard' support. Should I try to raise an issue on github instead? I would really like to assist with this topic, but I am not familiar with the required processes and, at the end, do not want to create more confusion than it's worth.

Hi everyone, I'm using the RTL8189FS WiFi module and noticed that the driver included in the current Armbian GitHub repository (https://github.com/armbian) seems to be quite outdated. I'd like to ask: - What is the current version of the RTL8189FS driver? - Is there a newer version available? Thanks in advance!

Checked http://fi.mirror.armbian.de/oldarchive/ ?

Hello everyone, I’m looking for an old Armbian image: Armbian 5.73 stable for NanoPi NEO Air, specifically the one based on Debian 10 (Buster) with the 4.19.20-sunxi kernel. Unfortunately, it’s no longer available in the Armbian archives. If anyone still has a copy of this image (e.g., Armbian_5.73_NanoPiNeoAir_Debian_buster_next_4.19.20.img.xz), I would be very grateful if you could share it or point me to a working download link. Thanks in advance for your help!

I just updated a raspios64 virtual machine with grub-efi and vanilla Debian kernel added: Settings in: /etc/default/raspi-firmware KERNEL=no INITRAMFS=no SKIP_INITRAMFS_GEN=yes Still: update-initramfs: Generating /boot/initrd.img-6.1.0-37-arm64 ERROR: Unsupported initramfs version (6.1.0-37-arm64) So it is not working as I hoped/thought.

Hi! I recently tried to install an image with pre-installed HA and, to put it briefly, I failed. Then I decided to go back to a clean installation of Armbian and install a supervised version of HA on it. I have already done this before, but I wanted to optimize the process with your images. And now I see that the HA team considers the supervised method unsupported. I do not have enough experience to bypass these restrictions in the future. Therefore, I decided to go back to your version. The issue is that these images do not have a boot partition. I tried to install using a flash drive with a boot partition from pure Armbian. But this trick did not work. Maybe this is completely impossible, but I hope you can tell me how to install it correctly. I am specifically interested in the image for Odroid C4, since it is for the same processor as the current TV box on Amlogic s903 x3.

On my up-to-date RPi4 server (Raspberry Pi OS 64-bit), dpkg -L lists all files in the (RPL variant of) raspi-firmware package. There are control files, scripts, hooks, license, readme, but the essential files are: /usr/lib/raspi-firmware/bootcode.bin /usr/lib/raspi-firmware/fixup*.dat /usr/lib/raspi-firmware/start*.elf Now RPi 3 4 5 differ what is needed. RPi3 only has ROM and uses bootcode.bin as sort of replacement/overlay/patch. PPi4 has this in EEPROM, so does not need bootcode.bin but I am not sure if it boots if the file is missing. RPI5 is radically different and AFAIR, does not need any of those 3 files, all bootloader code etc should be in EEPROM, I guess much like e.g. ROCK5B or so with U-Boot in SPI-flash. So that is also a reason that an RPI5 keeps booting/working even if you purged raspi-firmware (and that also deletes the copy on the bootFAT, check that, there were bugs in the .deb install script in the past). apt hold of the package keeps all the files original in the rootfs (and also the copies on bootFAT) so also /etc/initramfs/post-update.d/z50-raspi-firmware will still be there. It will be called every time a kernel version of initramfs is generated. For every kernel that is not from RPL, you hit the line: echo "ERROR: Unsupported initramfs version ($initrd_version)" in that script. As I indicated it is harmless if you happen to know what is in the script, but of course a bit of panic if not. A quick hack would be to comment out that line In the past (pre-Bookworm), for RPi3 and RPi4 I had an own extra script/hook that fetched 'latest version' of those 3 types of RPi files for 'firmware OS Linux Testing Opensuse' experiments and copied those to bootFAT. The core problem is that it is closed source, the only thing more or less sure is that steady improvement because RPL/RPT has long-term support even for their old 2012 Pi1. So how to do version control / management? I see there is also a settings file: /etc/default/raspi-firmware Maybe put several 'no' in there if your kernel is not the one from Raspberry Pi OS, which is the case for Armbian.

From time to time I see a message like this in my log files: 2025-06-05T11:29:33.367636+02:00 bananapipro2 kernel: [934985.549250] sysrq: HELP : loglevel(0-9) reboot(b) crash(c) terminate-all-tasks(e) memory-full-oom-kill(f) kill-all-tasks(i) thaw-filesystems(j) sak(k) show-backtrace-all-active-cpus(l) show-memory-usage(m) nice-all-RT-tasks(n) poweroff(o) show-registers(p) show-all-timers(q) unraw(r) sync(s) show-task-states(t) unmount(u) show-blocked-tasks(w) dump-ftrace-buffer(z) replay-kernel-logs(R) The system continues to work (although I remember that it stooped at this point in older releases). Is there any action required? I am afraid that this could stop my system which is running unattended for longer periods usually. I am running v25.2.2 for Banana Pi Pro running Armbian Linux 6.12.20-current-sunxi.

Thanks for the reply. I did run each element one at a time and watched to see when and if there were any that reported errors. It's not a big deal though and always worth trying new things to try and get this SOC running as it should do.

It works. On armbian: In /boot/armbianEnv.txt extraargs=ipv6.disable=1 Worked on my orangePi-PC2 at least. On rpiOS: In /boot/firmware/cmdline.txt, add ipv6.disable=1 to your console line, for example: console=serial0,115200 console=tty1 root=PARTUUID=583925ff-02 rootfstype=ext4 fsck.repair=yes ipv6.disable=1 rootwait You can check if it works: $ ls /proc/sys/net/ipv6 ls: cannot access '/proc/sys/net/ipv6': No such file or directory

I don't know if there is an option to disable ipv6 on bootloader level but that's not necessary anyway. You can do that in userspace via sysctl.conf, just use your favorite search engine and you will find how this works.

Without any research I assume this firmware package contains some fw files that are just there in case somebody wants to reflash some otherwise inaccessible fw storage. Similar to u-boot packages which on upgrade will store the necessary binaries for reflash on fs but does not actually reflash itself in the boot sector. Needs to be done manually. So tl;dr: having this optional makes sense.

https://zuckerbude.org/armbian-using-kernel-config/ Once successful tested provide a PR to add the missing module:https://docs.armbian.com/Process_Contribute/

Would like to be running fail2ban but missing an important kernel module -> xt_multiport Any ideas on obtaining this? modprobe: FATAL: Module xt_multiport not found in directory /lib/modules/6.12.22-current-rockchip64

that should be 1500000 (one more zero). Note a lot of uart connectors can't handle this high of a speed. There are many threads in the forums discussing specific ones that are able to reach that speed.

Well, for Home Assistant, Armbian / Debian Bookworm image is required. That we usually provide for all variants, supported and not supported. Since this hardware is not actively maintained, we don't know if there are any hardware level issues related to this board. Here you are on your own, hope for / wish you luck. Usually things works ... Next step is this: https://docs.armbian.com/User-Guide_Armbian-Software/HomeAutomation/#home-assistant It will provide the same result as image with pre-loaded Home Assistant.

Which image can be used for a orangepipc2 ? ( H5 processor, 1 Mb ram ?

I finally got my debugger, but I was not able to get any data from it. I successfully tested it on ESP32, but when I connected it to my Orange Pi 5 Max, there was no otuput. I tried with both baudrates: 150000 and 115200.

Probably. Only way to really find out is to try: https://www.armbian.com/amlogic-s9xx-tv-box

This will be fixed soon.

I started from scratch. Installed Armbian_25.2.2_Rpi4b_bookworm_current_6.12.15_minimal.img Having in mind what @eselarm suggested as culprit, I put raspi-firmware on hold root@rpi5b:~# apt-mark hold raspi-firmware then dpkg --remove --force-all libraspberrypi0 armbian-bsp-cli-rpi4b-current apt --fix-broken install apt install armbian-bsp-cli-rpi4b-current everything OK apt upgrade everything OK Reboot root@rpi5b:~# uname -a Linux rpi5b 6.12.31-current-bcm2711 #1 SMP PREEMPT Wed Jun 4 14:00:53 UTC 2025 aarch64 GNU/Linux Tried the same with raspi-firmware unhold and got this . . Setting up raspi-firmware (1:1.20250430-1) ... ERROR: Unsupported kernel version (6.12.15-current-bcm2711) Setting up libraspberrypi0:arm64 (1:2+git20231018~131943+3c97f76-1) ... Setting up libraspberrypi-bin (1:2+git20231018~131943+3c97f76-1) ... Processing triggers for libc-bin (2.36-9+deb12u9) ... Processing triggers for man-db (2.11.2-2) ... Processing triggers for initramfs-tools (0.142+deb12u1) ... update-initramfs: Generating /boot/initrd.img-6.12.15-current-bcm2711 W: Possible missing firmware /lib/firmware/rtl_nic/rtl8156b-2.fw for built-in driver r8152 W: Possible missing firmware /lib/firmware/rtl_nic/rtl8156a-2.fw for built-in driver r8152 W: Possible missing firmware /lib/firmware/rtl_nic/rtl8153c-1.fw for built-in driver r8152 W: Possible missing firmware /lib/firmware/rtl_nic/rtl8153b-2.fw for built-in driver r8152 W: Possible missing firmware /lib/firmware/rtl_nic/rtl8153a-4.fw for built-in driver r8152 W: Possible missing firmware /lib/firmware/rtl_nic/rtl8153a-3.fw for built-in driver r8152 W: Possible missing firmware /lib/firmware/rtl_nic/rtl8153a-2.fw for built-in driver r8152 ERROR: Unsupported initramfs version (6.12.15-current-bcm2711) I then did apt-mark hold raspi-firmware apt purge raspi-firmware and apt upgrade went through but the system is not in a good shape. root@rpi5b:~# uname -a Linux rpi5b 6.12.15-current-bcm2711 #1 SMP PREEMPT Wed Feb 19 13:49:50 UTC 2025 aarch64 GNU/Linux The /boot/firmware/initrd.img was not updated. Then I installed Armbian_25.2.4_Rpi4b_bookworm_current_6.12.22_minimal.img First thing after boot: root@rpi4b:~# update-initramfs -u update-initramfs: Generating /boot/initrd.img-6.12.22-current-bcm2711 ERROR: Unsupported initramfs version (6.12.22-current-bcm2711) The same with Armbian_25.5.1_Rpi4b_bookworm_current_6.12.28_minimal.img I don't have anymore a clean 25.2.3 but the homeassistant_minimal.img one has the same problem. No idea how to fix it. raspi-firmware has status optional and the 25.2.2 works OK without it, I think I will go this way hoping somebody with better skills then me will fix it one day. Regards, Chris

Wow, that was fast! But what about ipv6? It works on the community image for opi-PC2 as I mentioned but not here.. Edit. Nvm, I see there is a cmdline.txt file in there.. Thank you for the fast reply!

I tried to set the I2C interface with the armbian-config option but it doesn't work because it writes to the file: armbianEnv.txt .... overlays=sun50i-h6-i2c0 sun50i-h6-i2c1 sun50i-h6-i2c2 and it didn't work on my OrangePi3LTS and it doesn't start the i2C service on startup? but when I enter it manually: overlays=i2c0 i2c1 i2c2 then the i2c service works with my 40x2 LCD 🙂 ...is this a bug and if so can it be fixed? is the option: armbian-config still compatible with my OrangePi3 LTS?