All Activity

As far as I remember mostly works, with single ethernet, why not create new build with 6.15 and right dt file for 3B?

Thank you @SteeMan for pointing invalid value. Maybe this will help someone: For my configuration serial works only on UART2_TX_M0 and UART2_RX_M0. This is the log from my device: 9fffbe1e78 cym 24/02/04-10:09:20,fwver: v1.16 LPDDR5, 2400MHz channel[0] BW=16 Col=10 Bk=16 CS0 Row=16 CS=1 Die BW=16 Size=2048MB channel[1] BW=16 Col=10 Bk=16 CS0 Row=16 CS=1 Die BW=16 Size=2048MB channel[2] BW=16 Col=10 Bk=16 CS0 Row=16 CS=1 Die BW=16 Size=2048MB channel[3] BW=16 Col=10 Bk=16 CS0 Row=16 CS=1 Die BW=16 Size=2048MB Manufacturer ID:0xff CH0 RX Vref:27.9%, TX Vref:18.0%,0.0% CH1 RX Vref:27.1%, TX Vref:20.0%,0.0% CH2 RX Vref:26.7%, TX Vref:18.0%,0.0% CH3 RX Vref:25.4%, TX Vref:20.0%,0.0% change to F1: 534MHz change to F2: 1320MHz change to F3: 1968MHz change to F0: 2400MHz out U-Boot SPL board init U-Boot SPL 2017.09-armbian-2017.09-Sf73b-Pc965-H8c72-V6123-Bda0a-R448a (Aug 13 2 024 - 07:45:36) Trying to boot from MMC2 spl: partition error Trying fit image at 0x4000 sector ## Verified-boot: 0 ## Checking atf-1 0x00040000 ... sha256(7612223b82...) + OK ## Checking uboot 0x00200000 ... sha256(939bc88f65...) + OK ## Checking fdt 0x00354c30 ... sha256(e3b0c44298...) + OK fdt_record_loadable: FDT_ERR_BADMAGIC ## Checking atf-2 0xff100000 ... sha256(70505bb764...) + OK fdt_record_loadable: FDT_ERR_BADMAGIC ## Checking atf-3 0x000f0000 ... sha256(b2af21b504...) + OK fdt_record_loadable: FDT_ERR_BADMAGIC Jumping to U-Boot(0x00200000) via ARM Trusted Firmware(0x00040000) Total: 623.792/875.455 ms INFO: Preloader serial: 2 NOTICE: BL31: v2.3():v2.3-868-g040d2de11:derrick.huang, fwver: v1.48 NOTICE: BL31: Built : 15:02:44, Dec 19 2024 INFO: spec: 0x1 INFO: code: 0x88 INFO: ext 32k is valid INFO: ddr: stride-en 4CH INFO: GICv3 without legacy support detected. INFO: ARM GICv3 driver initialized in EL3 INFO: valid_cpu_msk=0xff bcore0_rst = 0x0, bcore1_rst = 0x0 INFO: l3 cache partition cfg-0 INFO: system boots from cpu-hwid-0 INFO: disable memory repair INFO: idle_st=0x21fff, pd_st=0x11fff9, repair_st=0xfff70001 INFO: dfs DDR fsp_params[0].freq_mhz= 2400MHz INFO: dfs DDR fsp_params[1].freq_mhz= 534MHz INFO: dfs DDR fsp_params[2].freq_mhz= 1320MHz INFO: dfs DDR fsp_params[3].freq_mhz= 1968MHz INFO: BL31: Initialising Exception Handling Framework INFO: BL31: Initializing runtime services WARNING: No OPTEE provided by BL2 boot loader, Booting device without OPTEE init ialization. SMC`s destined for OPTEE will return SMC_UNK ERROR: Error initializing runtime service opteed_fast INFO: BL31: Preparing for EL3 exit to normal world INFO: Entry point address = 0x200000 INFO: SPSR = 0x3c9 No valid device tree binary found - please append one to U-Boot binary, use u-bo ot-dtb.bin or define CONFIG_OF_EMBED. For sandbox, use -d <file.dtb> initcall sequence 00000000002d2af8 failed at call 00000000002c5028 (err=-1) ### ERROR ### Please RESET the board ###

Hi, it looks like you or a process is triggering the SysRq key. For example, If I press Alt + PrtSc (SysRq) + h, I see the same message in dmesg. https://en.wikipedia.org/wiki/Magic_SysRq_key

If you follow the instructions earlier in this thread, you can use the Armbian build framework to build an image for aml-s9xx-box with the HA additions, or just use armbian-config to add it. I haven't tested any of those, as I just install the regular docker based HA on my home TV box to run HA.

Not sure what you mean by outdated? Gets updated often or when needed; https://github.com/jwrdegoede/rtl8189ES_linux/tree/rtl8189fs

Welcome to submit PR here: https://github.com/armbian/build/tree/main/config/kernel Best to all those configs:

I think this is handled with overlay "audio" "analogue" or something similar. https://docs.armbian.com/User-Guide_Armbian-Config/System/#device-tree-overlays

I think I wasn't clear: HDMI audio is working, built-in audio is not. I'm using the latest edge image from Armbian that is 6.15. It's strange that I can see in Gnome Config the audio ports correctly HDMI and Built-In.

Did you figured out what is the reason for this problem with dark pictures?

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 and similar (volunteer based) projects that deals with Linux wireless. 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 such drivers to mainline code, but I doubt this chip will ever find a way there - and this doesn't mean that it will work better. 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