Search the Community

I don't believe mainline kernels support the NAND, and aren't likely to as it is flaky. I would try whatever the current image is and see what you get.

Description It is known that it is built without errors and works on a test platform. freeze the kernel version v6.6.31 sunxi-6.6: rework patches for current v6.6.31 [ ] short description (copy / paste of PR title) [ ] summary (description relevant for end users) [ ] example of usage (how to see this in function) How Has This Been Tested? Please describe the tests that you ran to verify your changes. Please also note any relevant details for your test configuration. [x] Build & Test on board Bananapi-m64 View the full article

[ LINUXFAMILY='rockchip64' ] Try to freeze the kernel version for the target family. Apply this patch to the build system itself. fix-6.6.30-version.patch cd /mnt/music/Armbian/build ls ../fix-6.6.30-version.patch ../fix-6.6.30-version.patch git status git restore file1 file2 .... git pull patch -p1 -i ../fix-6.6.30-version.patch Put the patch in a /mnt/music/Armbian/ folder. Check the status and if there are modified files, do the following: git restore "list files" All this is for the main branch P.S. Try to make an assembly. And please post the log.

I have got the same issue. Orange Pi Zero H2+ Linux moblink 6.6.16-current-sunxi #1 SMP Fri Feb 23 08:25:28 UTC 2024 armv7l GNU/Linux Armbian 24.2.1 I used some software which is 1) playing some sound into embedded sound card 2) processing interrupts on gpio (gpio event with GPIO API V2) During sysstat-collect.service failing for 1min 47.293s: +sound playing OK - gpio interrupts proccessing freeze I had to stop and disable sysstat-collect.service Also apt remove sysstat It helped. cat armbian-image-release cat armbian-release cat os-release

Thank you for reply. I've already boot from SD with a new image. I've tested several different kernels up to 6.8.9, nothing changed. Also I've already try to toggle different armbian-configuration params related to HDMI, also no luck

Hello, If you boot from SD card, testing a new image will help you diagnose the problem. I have been booting from the 6.x.y kernels up to 6.8.9 and get HDMI OK. I notice the kernel you use is 5.10.160. G

I don't know for sure but my guess is yes, you need the sd to hold the boot loader at least. NAND was supported only with stone-age 3.x kernels which have been abandoned years ago. Therefore this can no longer be used.

I would not use ZFS with this kernel if I were you. This kernel is provided by hw vendor, by people / business that only cares about (selling) hardware features to work. Everything else is unmaintained and open source community (not just Armbian) developers are not even thinking to maintain this kernel outside that as its concorde fallacy. FYI - it is highly possible ZFS implementation is affected, but you are FREE to do whatever. 90% of solutions, not workarounds, Armbian team (a few people) is unable to integrate into OS with their private resources, public (thousands of you) are simply not there. I can estimate, we could integrate about 30% of resolved suggestions this community generate with few full time engineers. Which costs money. Until you are satisfied with reporting problems only, until you don't care that a lot of value is wasted, there is nothing we can do but keep trying to provide "best effort" support with what we have and explaining this situation. Users perspective will always be like we refuse to help ... but people that are working on / helping Armbian are already long maxed out in efforts of helping everyone, even our competitors. Also. Hardware vendors have exploit of open source community build into their business model. If it happens that you are using hardware with terrible vendors reputation, bugs can be written, but are last to be resolved, some bugs are never resolved ... If you really wanna help everyone, start here: https://github.com/armbian/os/wiki/Import-3rd-party-packages Study and implement a solution. We also have automated dependency testing, which should prevent this problem in first place, but ain't working well and it wouldn't help much in this case. ZFS package is imported from Trixie and yes I understand that upstream package dependency has been recently changed. Until a month ago, we didn't have this problem, everything was working right and now, there is little we can do except disabling importing (which will also delete packages from repository). We don't compile those packages on our own and I am aware that this is not the best way. There are more workarounds - like using Trixie or Noble user space ... Its sadly under-powered, too small. Math is simple - I would very much like to help, but costs are the one that are killing us. Imagine that fixing a problem costs 1000 USD. You are willing to pay 5 USD (or not even that), which is fair if there would be more people contributes their share that you cover all costs. This never happens. They come with another and another problem for 1000 USD (often a lot more, sometimes a lot less) instead. Then its expected that we pay the rest, 995 USD for costs of resolving community software problem, this is simply not sustainable way of cooperation. Even the bug was made by us. I am trying to keep ZFS available. Do you have any idea how much time loss this service already caused with no benefits whatsoever? There are thousands of bugs in open source software and most of people pin everything on us after they download "Armbian image" and images that are produced by copycats as they claim "its Armbian". This particular problem was introduced by us, yes, but alternatively would be not providing ZFS that is capable of working with recent kernels. Which touches to the core of embedded Linux experience and logic. Often we can't match user space and kernel like this is done on 1st class x86 desktop / server / hw Linux world. Even they, often breaks critical things too, even with thousands of full time employees (Redhat). We can't provide that level of services with close to nothing from your side.

Hi all, I have some x905 boxes and I'd like to use one (an old TX95 -> x905w IIRC) as a midi sequencer with fluidsynth. I found the hard way that the default kernel has no midi sequencer support (in kernel or module) so there's no way to use aconnect and have it as a midi box. The only solution seems to be rebuild the kernel with the added module support but it's been decades since last time i rebuilt a kernel and S905 kernels (with added balbes150 mods and stuff to have it working on those cheap boxes) seems a bit too complex for me. So the question is: is there a way to get a working kernel with midi support, and how to put it in. If this wasn't really feasable: how could a mere mortal (with some knowledge) rebuild an x905w kernel, pack it and install without breaking the whole thing in the process ? ( I'm not interested in a GUI or similar, it would work as headless with the RCA out for audio )

Hi all, Just want to share this issue i came across from my recently purchased OPI5+ 32GB version. I noticed it freezes when transferring .img from micro SD card to eMMC or NVMe drives via the command line. Now the img file are armbian OS and no its not the img file issue. at times I can get it to around 70seconds and it will freeze. hard reboot is required, unable to complete the transfer. I have also tried to reduce the bs=10 speed but still the same. Now i have also got the 16GB version and this works fine with no issues... Good chance there is something wrong with this latest hardware.. ? ?

Hello everyone, I've recently started migrating a project for Banana Pi M5 from Debian 10 Buster to Armbian, because I've found that the latest versions of it now support the GPU, Mali G31, and come with Panfrost OpenGL driver, which is crucial for this project. Everything was perfect until I had to implement two features: operating with TV via CEC and showing boot logo. Quickly about the last one - as I've understood, we have to use Plymouth, but I didn't really get how to do it, I've tried to activate it but had no success (how exactly see under paragraph). However, it doesn't work on Server Images (even on those that were compiled with build tools and activated option BOOT_LOGO in kernel conf), but in GUI Images everything is fine with it. Also I've tried using uBoot logo (boot-logo.bmp.gz), but also no success. # Adding "splash quiet loglevel=0 logo.nologo" to extraargs in "/boot/armbianEnv.txt" # Activating bootlogo in "/boot/boot.cmd" (am I even supposed to edit this file?) sudo plymouth-set-default-theme -R customtheme # It contains our logo # sudo update-initramfs -c -u # In fact, it runs automatically sudo reboot # ... sudo plymouthd sudo plymouth --show-splash Now about CEC. I've made some observations: CEC Under Debian # Sorry, there is no support for Shell syntax highlighting apparently. pi@TEST:~$ uname -a Linux TEST 4.9.312-BPI-M5 #1 SMP PREEMPT Wed Mar 1 01:44:35 UTC 2023 aarch64 GNU/Linux pi@TEST:~$ cec-client -l libCEC version: 4.0.4, compiled on Linux-4.9.0-8-arm64 ... , features: P8_USB, DRM, P8_detect, randr, Exynos, AOCEC Found devices: 1 device: 1 com port: AOCEC vendor id: 0000 product id: 0000 firmware version: 5 type: unknown pi@TEST:~$ ls -l /dev/*cec* crw-rw-rw- 1 root root 503, 0 Feb 14 2019 /dev/aocec pi@TEST:~$ echo 'standby 0' | cec-client -s -d 1 opening a connection to the CEC adapter... pi@TEST:~$ # Works fine. pi@TEST:~$ echo 'on 0' | cec-client -s -d 1 opening a connection to the CEC adapter... pi@TEST:~$ # Works fine. pi@TEST:~$ sudo lsmod | grep cec pi@TEST:~$ sudo find /lib/modules/ -name "*cec*" pi@TEST:~$ # No CEC module in lsmod or modules overall, but works fine. pi@TEST:~$ It uses AOCEC on 4.9 Linux kernel. Works flawlessly. All the parts in "/boot/boot.ini" concerning CEC: ... ### voutmode : hdmi or dvi setenv voutmode "hdmi" # setenv voutmode "dvi" # HPD enable/disable option setenv disablehpd "false" # Enable/Disable CEC setenv cec "true" ... ### Normal HDMI Monitors if test "${display_autodetect}" = "true"; then hdmitx edid; fi if test "${hdmimode}" = "custombuilt"; then setenv cmode "modeline=${modeline}"; fi if test "${cec}" = "true"; then setenv cec_enable "hdmitx=cec3f"; fi ... # Boot Args setenv bootargs "...${cec_enable} sdrmode=${sdrmode}" ... If I set cec "false" this happens: pi@TEST:~$ cec-client -l libCEC version: 4.0.4, compiled on Linux-4.9.0-8-arm64 ... , features: P8_USB, DRM, P8_detect, randr, Exynos, AOCEC Found devices: 1 device: 1 com port: AOCEC vendor id: 0000 product id: 0000 firmware version: 5 type: unknown pi@TEST:~$ ls -l /dev/*cec* crw-rw-rw- 1 root root 503, 0 Feb 14 2019 /dev/aocec pi@TEST:~$ echo 'standby 0' | cec-client -s -d 1 opening a connection to the CEC adapter... unable to open the device on port AOCEC ERROR: [ 2233] AllocateLogicalAddresses - failed to allocate device '0', type 'recording device' ERROR: [ 2233] failed to find a free logical address for the client ERROR: [ 2233] failed to register the new CEC client - cannot allocate the requested device types ERROR: [ 2233] failed to register a CEC client pi@TEST:~$ # Doesn't work pi@TEST:~$ Here, "/dev/aocec" doesn't sweep away when setting CEC to false. It just becomes unaccesible. CEC Under Armbian pi@TEST:~$ uname -a Linux TEST 6.6.8-edge-meson64 #1 SMP PREEMPT Wed Dec 20 16:02:07 UTC 2023 aarch64 GNU/Linux pi@TEST:~$ cec-client -l libCEC version: 6.0.2, compiled on Linux ... , features: P8_USB, DRM, P8_detect, randr, Exynos, Linux, AOCEC Found devices: NONE pi@TEST:~$ ls -l /dev/*cec* ls: cannot access '/dev/*cec*': No such file or directory pi@TEST:~$ echo 'standby 0' | cec-client -s -d 1 autodetect FAILED pi@TEST:~$ echo 'on 0' | cec-client -s -d 1 autodetect FAILED pi@TEST:~$ sudo lsmod | grep cec pi@TEST:~$ sudo find /lib/modules/ -name "*cec*" /lib/modules/6.6.8-edge-meson64/kernel/drivers/media/cec /lib/modules/6.6.8-edge-meson64/kernel/drivers/media/cec/usb/pulse8/pulse8-cec.ko /lib/modules/6.6.8-edge-meson64/kernel/drivers/media/cec/usb/rainshadow/rainshadow-cec.ko /lib/modules/6.6.8-edge-meson64/kernel/drivers/media/cec/platform/cec-gpio /lib/modules/6.6.8-edge-meson64/kernel/drivers/media/cec/platform/cec-gpio/cec-gpio.ko /lib/modules/6.6.8-edge-meson64/kernel/drivers/media/cec/platform/meson/ao-cec.ko /lib/modules/6.6.8-edge-meson64/kernel/drivers/media/cec/platform/meson/ao-cec-g12a.ko /lib/modules/6.6.8-edge-meson64/kernel/drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.ko pi@TEST:~$ sudo modprobe cec pi@TEST:~$ sudo modprobe cec-gpio pi@TEST:~$ sudo modprobe ao-cec pi@TEST:~$ sudo modprobe ao-cec-g12a pi@TEST:~$ sudo modprobe dw-hdmi-cec pi@TEST:~$ sudo modprobe pulse8-cec pi@TEST:~$ sudo modprobe rainshadow-cec pi@TEST:~$ sudo lsmod | grep cec rainshadow_cec 16384 0 pulse8_cec 24576 0 dw_hdmi_cec 12288 0 ao_cec_g12a 12288 0 ao_cec 16384 0 cec_gpio 12288 0 pi@TEST:~$ # cec.ko isn't in libs so in lsmod there is no such module, but why "modprobe cec" gives no error? pi@TEST:~$ ls -l /dev/*cec* ls: cannot access '/dev/*cec*': No such file or directory pi@TEST:~$ # And activating modules just doesn't help, there is still no any "/dev/*cec*" device pi@TEST:~$ It doesn't use any of CEC on 6.6.8 Bleeding Edge Linux kernel (I've tested it before on stable 6.1 kernel, but it didn't work as well, I've activated some modules concerning CEC in kernel config and built using the latest possible kernel, thinking it will change something). Just doesn't work. AOCEC module is compiled and launched though, but it doesn't use it at all since there is no "/dev/*cec*" device. All the parts in "/boot/boot.cmd" concerning CEC: ... setenv sdrmode "auto" setenv voutmode "hdmi" setenv disablehpd "false" setenv cec "false" ... if test -e ${devtype} ${devnum} ${prefix}zImage; then ... setenv bootargs "...${cec_enable} sdrmode=${sdrmode}" ... Somehow, it misses the part where we should set "cec_enable" variable. What if I restore it and set to true? But I don't really think it will change something, as "/dev/aocec" existed on Debian even when CEC was disabled. That didn't work, as well as adding "hdmitx=cec3f" to extraargs in "/boot/armbianEnv.txt". There is just no CEC device in "/dev/", I don't know which type of problem is that - module, overlay, kernel?? Yes, I've used v4l, and it also fails because it doesn't find any "/dev/*cec*". Anyway, I hope this problem can be resolved and thanks to everyone for attention, have a happy new 2024 year!

Thanks for the suggestion. There was no option for kernels in armbian-config -> software. I there was an option to switch to nightly in armbian-config -> system and I executed that. It installed a new kernel and now the system hangs on the 4 pixel rainbow screen. I should probably have mentioned that this is on a Pi CM4 booting from an NVME SSD. I'm trying things out on that to avoid swapping NVME SSDs on my Pi 5. I'm aware that RpiOS runs different kernels on Pi 4 vs. Pi 4B/CM4 but they install both and choose the correct one during boot.

Good evening, Armbian noob here (Debian veteran) working with an RPi 5. I've just installed `Armbian_24.2.5_Rpi5b_bookworm_current_6.6.23.img.xz` and would like to build the ZFS modules. I've installed the kernel modules using `armbian-config` but when I try to build I get root@meson:~# dpkg-reconfigure zfs-dkms Deleting module zfs-2.2.3 completely from the DKMS tree. Loading new zfs-2.2.3 DKMS files... Building for 6.6.23-current-bcm2712 Module build for kernel 6.6.23-current-bcm2712 was skipped since the kernel headers for this kernel do not seem to be installed. root@meson:~# Edit: Current situation: root@meson:~# dpkg -l linux-headers-current-bcm2712 linux-image-current-bcm2712 Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-=============================-============-============-========================================================= ii linux-headers-current-bcm2712 24.2.1 arm64 Armbian Linux current headers 6.6.18-current-bcm2712 ii linux-image-current-bcm2712 24.2.5 arm64 Armbian Linux current kernel image 6.6.23-current-bcm2712 root@meson:~# It seems that the headers for this kernel are not available. `armbian-config` lists only a newer kernel as an option (6.7) `apt search` lists older kernels, probably from the Debian repos. Can I switch to these or is there something else I can do? Thanks! (First post here.)

Switch to nightly kernels (those are becoming stable in two weeks anyway), update, reboot. Remove / Add kernels and it will work. Use armbian-config -> software to make this easy way. Welcome!!!

@cad 435 No you aren't really missing anything. In the stable channel, kernel .debs generally only get pushed out every three months when a new stable release is put out (24.05 will be out the end of this month for example). If you want to get regular updates of kernels you need to switch to the nightly builds repository in armbian-config. Right now there is no in between.

This is hard to say as we are talking about non standard Linux kernel. If HA works, IMO you can safely ignore those problems or: New kernel is being developed for several years and it might already be working for this use case. You can try by switching to it (armbian-config -> system -> alternative kernels -> select EDGE 6.8.something), but I give you no warranty that it will work. You might need to start with a new image. If it works well, report back and we will generate images by using that kernel. I know many things in graphical areas are missing there, but for this uses case we don't need HDMI output anyway ...

Hello @primoitt , yes it has been deprecated. It wasn't developer anymore, now has been fully removed. You can find the latest iteration with the legacy kernel for rk322x family on this branch. After that, rk322x and rockchip familes have been merged and legacy kernels removed because old and unmaintained. The main reason to keep legacy was raw NAND support, but we at last we decided it does not worth the effort to keep it.

Description Various minor fixes to rockchip rk3318/rk322x based tv boxes: usb ports gain resets in uboot and kernel, so hopefully they gains some more compatibility and/or less hangups rk3318-box now uses the ddrbin from vendor; it was accidentally switched to uboot TPL during last uboot update some patches have been removed because useless or because things could merged into board dtbs Except for a change in dwc2.c driver in rockchip 32 bit (that may have an effect on OTG port on ASUS Tinkerboard, which is usually unused due to being the power connector), no other boards are affected by these changes. It looks like that USB resets,at least on rk3318/rk3328, are good for USB gadgets and makes the audio gadget work in both UAC1 and UAC2 modes. During previous tests, without these patches, audio gadget were totally refusing to work. How Has This Been Tested? USB device have been tested on all USB OTG/EHCI or hubbed ports on these systems: [x] Tested current 6.6 kernel on rk322x live system, complied edge 6.8 kernel [x] Tested current 6.6 kernel on rk3318 live system [x] Tested current 6.6 and edge 6.8 kernels on rk3328 live system Checklist: [x] My code follows the style guidelines of this project [x] I have performed a self-review of my own code [x] I have commented my code, particularly in hard-to-understand areas [x] My changes generate no new warnings View the full article

Hi all, First post here. I have been running Armbian on my original Bananapi Pro for a long while now, and thought that it's time to upgrade from Bullseye to Bookworm finally. There were some complications with UsrMerge that I had to resolve manually (I think some boot files from the original Buster installation were both in /lib and /usr/lib), but apart from that the upgrade appears to have worked: All userspace stuff is on Bookworm. # lsb_release -a No LSB modules are available. Distributor ID: Debian Description: Armbian 24.5.0-trunk.530 bookworm Release: 12 Codename: bookworm However, the kernel seems to be stuck on 5.15: # uname -a Linux bananapi 5.15.43-sunxi #22.05.1 SMP Sat May 28 08:17:47 UTC 2022 armv7l GNU/Linux This version number appears to be inconsistent with the contents of armbian-image-release: # cat /etc/armbian-image-release # PLEASE DO NOT EDIT THIS FILE BOARD=bananapipro BOARD_NAME="Banana Pi Pro" BOARDFAMILY=sun7i BUILD_REPOSITORY_URL=https://github.com/armbian/build BUILD_REPOSITORY_COMMIT=85080ff3 VERSION=5.99.191113 LINUXFAMILY=sunxi BRANCH=dev ARCH=arm IMAGE_TYPE=nightly BOARD_TYPE=eos INITRD_ARCH=arm KERNEL_IMAGE_TYPE=zImage IMAGE_UUID=1b7fd79e-803f-4438-8b4c-5e9287a7b86c I saw on the download page that a current download of Armbian Bookwork for the Bananapi Pro would include Kernel 6.6.29, so there should be a newer kernel available. Can you help me troubleshooting what is holding my system back from upgrading to a newer kernel? Various posts on the forum suggest anything from "apt-get upgrade will update your kernel" to "use armbian-config". Using the latter, I tried switch between nightly and stable, which didn't offer any updated kernel to apt. The "Switch to other kernels" option retrieves some files, then shows the "Yes, I understand" screen but then immediately goes back to the main "System settings" screen, which makes me think that something is broken here. How can I find out what exactly is broken?

This is just one issue out of thousands and we operate all this with budget that is very close to zero. This should be picked by maintainer, if exists. We support them from our business deals, but still, they come and go and in between, we have nobody. For a month and half, there is nobody and I can't cover, its too expensive. Since none of board maintainer is full time, but they should be, this can easily take weeks, or more ... But luckily: automated builds makes it half way. Its there, even smoke tested, where problems are not detected. one can build combo on their own. its open source. You can fix bugs too. we need to push new release by the end of the month. And yes, I heard there are some problems with Rpi kernels. Which will just make us more damages and headaches. Rpi foundation has almost 2 mio EUR yearly budget to fight problems ... Its not Armbian that is making bugs, but you expect us to pay to fix them. I tried to help you with hints. Here I have to stop. Out on vacations.

Did you reboot before (re)installing headers? If yes and still not ok ... beta repository certainly has matched kernel / headers combo. IMO its pretty safe to upgrade to daily builds, but then freeze kernel (can be done in armbian-config).

I think you were dead-on in your previous post - the armbian-bsp-cli-bananapipro package was not installed anymore. After installing that, the "Switch to other kernels" option started working again, and I have a choice of three kernels now! But before I proceed and install the new kernel - I noticed that the linux-u-boot-bananapipro-current package is also not installed. I'm not sure how critical that is, and if just installing the new kernel would be enough. Should I install it manually before proceeding?

Thank you for your reply. I suppose you mean the "Switch to other kernels" option? As said, it doesn't seem to be working, and I think I have a hunch now why that might be the case: Running "dpkg -l | grep linux-image", the output is completely empty. Or is this option looking for something completely different?

Looks like you have the vendor kernel package installed. If you want mainline kernel, then you need to install the current kernel package. Run armbian-config and see what it tells you are the available kernels for you. Now realize that going from vendor to mainline kernel you might loose some functionality (there is an FAQ item on this), but you can always switch back to vendor kernel if it is important.

okok, i do one pass with my setting and if not crash, i try GOVERNOR=ondemand after, my pattern test during 36-40hours, keep in touch after this time if i not crash/freeze before