Search the Community

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!

Description The idea is to generate output/git_sources.json file that will contain url, branch and commit hash combo. The easiest way to generate file for all devices is to run ./compile.sh targets. Then at the time of release we will copy the output/info/git_sources.json file to config/sources/git_sources.json. Once the file is copied, the hash information from the file will be used to fetch resources for git repositories where branches are specified instead of tags or commits. There can be other ways to do this as well. I am just too tired to experiment more on the same. Raising it to be a communication starter. Jira reference number AR-2087 Based on: https://github.com/armbian/build/pull/6272 How Has This Been Tested? [ ] Tested output/git_sources.json file generation using ./compile.sh targets command [ ] Copied generated file to config/sources and modified it to use a different commit hash for 6.6 kernel. Then tested that kernel is being built from that hash instead of the latest available 6.6 kernel. Checklist: [ ] My code follows the style guidelines of this project [ ] I have performed a self-review of my own code [ ] I have commented my code, particularly in hard-to-understand areas [ ] I have made corresponding changes to the documentation [ ] My changes generate no new warnings [ ] Any dependent changes have been merged and published in downstream modules View the full article

Description The idea is to generate output/git_sources.json file that will contain url, branch and commit hash combo. The easiest way to generate file for all devices is to run ./compile.sh targets. Then at the time of release we will copy the output/git_sources.json file to config/sources/git_sources.json. Once the file is copied, the hash information from the file will be used to fetch resources for git repositories where branches are specified instead of tags or commits. There can be other ways to do this as well. I am just too tired to experiment more on the same. Raising it to be a communication starter. I have also added the json file that I have generated today. I think it can be used to freeze sources for 24.02 release. Hence I have raised this PR again v24.02 branch 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. [ ] Tested output/git_sources.json file generation using ./compile.sh targets command [ ] Copied generated file to config/sources and modified it to use a different commit hash for 6.6 kernel. Then tested that kernel is being built from that hash instead of the latest available 6.6 kernel. Checklist: [ ] My code follows the style guidelines of this project [X] I have performed a self-review of my own code [ ] I have commented my code, particularly in hard-to-understand areas [ ] I have made corresponding changes to the documentation [X] My changes generate no new warnings [ ] Any dependent changes have been merged and published in downstream modules View the full article

Hi guys, i'm running transmission-daemon 3.00 on my orange pi 5 where there is installed Armbian based on ubuntu jammy. It works fine, but recently i've reached the number of 78 torrents that i'm downloading and seeding, i do not think it's an high number of files shared. Anyway after some hours that i start transmission-daemon i do not know the reason, it seems that is not downloading and seeding anything. I mean that the interface and the process are running and active but every torrent file it seems freezed. If i restart the process, everything start to work properly. I'm not an expert, if someone can tell me how to gather the logs i can share with you more informations. This problem started recently (last month), because some months ago i left the orange pi active for some months without switching it off and was working fine. I do not know if it is the quantity of torrent active (78), but it should not be a problem. I've done the same question here: https://answers.launchpad.net/ubuntu/+source/transmission/+question/709114 But they told me to make this question here on Armbian. If someone can help me please

Hi, I use Helios64 from the begin and this board is very unstable according to my experience and many posts here... After many dialogue here and settings shared about Frequency and Governor Kernel... maybe i find the problem and i ask anyone return of experiences about the procedure and setting belong: - Connect USB Wireless Dongle or USB(-c) Ethernet Plug - Configure it - Disconnect all ethernet cable to the board - Use with last time crash configuration and do a endurance test your helios64 board Have a good day

Description Bump all mainline based kernels. How Has This Been Tested? [ ] Build test within CI Checklist: [x] My code follows the style guidelines of this project [ ] My changes generate no new warnings View the full article

Description Legacy - 5.15.x -> 6.1.x Current - 6.1.x -> 6.6.x Edge - 6.6.x -> 6.7-rc6 move kernel branch and minor definitions to config/sources/common.conf (this location was predicted to contain this) bump UEFI kernels fix Phytium patch compilation failure for 6.7.y removed old leftover kernel patch directories Jira reference number AR-2005 How Has This Been Tested? [x] Patching test Checklist: [ ] My code follows the style guidelines of this project [ ] I have performed a self-review of my own code [ ] I have commented my code, particularly in hard-to-understand areas [ ] I have made corresponding changes to the documentation [ ] My changes generate no new warnings [ ] Any dependent changes have been merged and published in downstream modules View the full article

Description Bump Allwinner kernels Legacy - 5.15.x -> 6.1.x Current - 6.1.x -> 6.6.x Edge - 6.6.x -> 6.7-rc6 Removed old leftover kernel patch directories. 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. [ ] Edge kernel builds with EXTRAWIFI=no. Some driver harness drivers including xradio, rtl8189es, rtl8189fs, rtl8812au, rtl8192eu and possibly others needs some fixes as compilation fails for the same. Checklist: [ ] My code follows the style guidelines of this project [ ] I have performed a self-review of my own code [ ] I have commented my code, particularly in hard-to-understand areas [ ] I have made corresponding changes to the documentation [ ] My changes generate no new warnings [ ] Any dependent changes have been merged and published in downstream modules View the full article

Description Bumping to latest lts versions Checklist: [ ] My code follows the style guidelines of this project [ ] I have performed a self-review of my own code [ ] I have commented my code, particularly in hard-to-understand areas [ ] I have made corresponding changes to the documentation [ ] My changes generate no new warnings [ ] Any dependent changes have been merged and published in downstream modules View the full article

Description This should get wifi working on OrangePi Zero2 on current and edge kernel 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] Not tested as I don't have the device. @AGM1968 Could you please test the same? Checklist: [ ] My code follows the style guidelines of this project [ ] I have performed a self-review of my own code [ ] I have commented my code, particularly in hard-to-understand areas [ ] I have made corresponding changes to the documentation [ ] My changes generate no new warnings [ ] Any dependent changes have been merged and published in downstream modules View the full article

Description As per title. How Has This Been Tested? [ ] Build test at CI Checklist: [ ] My changes generate no new warnings View the full article

Description As per tittle. How Has This Been Tested? [ ] Build test, will run smoke tests right after too. Checklist: [ ] My code follows the style guidelines of this project [ ] I have performed a self-review of my own code [ ] I have commented my code, particularly in hard-to-understand areas [ ] I have made corresponding changes to the documentation [ ] My changes generate no new warnings [ ] Any dependent changes have been merged and published in downstream modules View the full article

WSL2 "boards" wsl2-x86/wsl2-arm64 with current (6.1.y) and edge (6.6.y) kernels with Microsoft patches WSL2 "boards" wsl2-x86/wsl2-arm64 with current (6.1.y) and edge (6.6.y) kernels with Microsoft patches tl,dr: add 4 small-ish UEFI-like kernels, with Microsoft patches & fixes, for use with Microsoft WSL2 on x86/arm64 and 6.1.y/6.6.y the boards are UEFI derivatives, using a common microsoft vendor include to modify KERNELPATCHDIR/LINUXFAMILY (for now, we don't want those patches in regular UEFI builds / .debs) disable EXTRAWIFI (kernel is for a VM, will never have wifi so doesn't need any drivers) LINUXCONFIG, so we can use Microsoft's own monolithic kernel, required for WSL2 (their initrd is a mistery) really, what we're mostly interested right now are the kernels (in the future we might have an "Armbian" WSL2 app in the Microsoft Store) current 6.1.y: rebased from https://github.com/microsoft/WSL2-Linux-Kernel/tree/linux-msft-wsl-6.1.y onto real 6.1.y using Microsoft's .config exactly (monolithic, there are no =m's) edge 6.6.y: also from https://github.com/microsoft/WSL2-Linux-Kernel/tree/linux-msft-wsl-6.1.y but rebased onto 6.6.y using updated Microsoft's .config (monolithic, there are no =m's) dropped 2 of 6.1.y's patches that were actually upstreamed in the meantime: mm-page_reporting-Add-checks-for-page_reporting_order-param - mainlined in https://lore.kernel.org/all/1664517699-1085-2-git-send-email-shradhagupta@linux.microsoft.com/ hv_balloon-Add-support-for-configurable-order-free-page-reporting - mainlined in https://lore.kernel.org/all/1664517699-1085-3-git-send-email-shradhagupta@linux.microsoft.com/ drop the arm64: hyperv: Enable Hyper-V synthetic clocks/timers patch, since it causes asm breakage on 6.6.y a shame, but I tried and can't fix it myself - @kelleymh ? add my own patch to fix: 1709-drivers-hv-dxgkrnl-restore-uuid_le_cmp-removed-from-upstream-in-f5b3c341a.patch due to https://lore.kernel.org/all/20230202145412.87569-1-andriy.shevchenko@linux.intel.com/ landing in 6.6 1710-drivers-hv-dxgkrnl-adapt-dxg_remove_vmbus-to-96ec29396-s-reality-void-return.patch to adapt to https://lore.kernel.org/all/TYCP286MB2323A93C55526E4DF239D3ACCAFA9@TYCP286MB2323.JPNP286.PROD.OUTLOOK.COM/ wsl2: detect Armbian-built wsl2 kernel as well as Microsoft's default kernel previous commit introduces Armbian wsl2 kernels, might as well detect them View the full article

Description Bumped Allwinner kernels. legacy - 5.15.137 -> 5.15.139 current - 6.1.62 -> 6.1.63 edge - 6.6.1 -> 6.6.2 Updated ov5640 camera patches to fix patch application failure. Also rebased the config files. 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] Both 32-bit and 64-bit kernel builds fine. [X] Tested 32-bit kernel on NanoPi Duo2(H3). All 3 kernels seems to work fine. [X] Tested ov5640 camera with current and edge kernels. Autofocus didn't worked for me, but its possible that I might have damaged my camera by placing something on it. Have to retest with an older kernel later to make sure. But video capture worked fine. Checklist: [ ] My code follows the style guidelines of this project [ ] I have performed a self-review of my own code [ ] I have commented my code, particularly in hard-to-understand areas [ ] I have made corresponding changes to the documentation [ ] My changes generate no new warnings [ ] Any dependent changes have been merged and published in downstream modules View the full article

Description In the tittle. How Has This Been Tested? [ ] Build test View the full article

Description These are dead kernels with no ties to either vendor or mainline support. Remove patchsets to reduce clutter and confusion for any/all future contribution. (Example: Fixes should be posted to all LTS and current stable mainline kernel, not to these dead ones) How Has This Been Tested? Kernels have to be manually selected be editing config files, they aren't being used in the build system itself, any niche use for them can be accomplished by pulling them from history by the user. Checklist: [ ] My code follows the style guidelines of this project [ ] I have performed a self-review of my own code [ ] I have commented my code, particularly in hard-to-understand areas [ ] I have made corresponding changes to the documentation [ ] My changes generate no new warnings [ ] Any dependent changes have been merged and published in downstream modules View the full article

Description As per description. How Has This Been Tested? [x] Patch test 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 [ ] I have made corresponding changes to the documentation [ ] My changes generate no new warnings [ ] Any dependent changes have been merged and published in downstream modules View the full article

Description Legacy - 5.15.135 -> 5.15.137 Current - 6.1.57 -> 6.1.60 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] Both 32-bit and 64-bit Kernel builds [X] Booted on Orange Pi Zero, Orange Pi 3-LTS Checklist: [ ] My code follows the style guidelines of this project [ ] I have performed a self-review of my own code [ ] I have commented my code, particularly in hard-to-understand areas [ ] I have made corresponding changes to the documentation [ ] My changes generate no new warnings [ ] Any dependent changes have been merged and published in downstream modules View the full article

Description Legacy - 5.15.134 -> 5.15.135 Current - 6.1.56 -> 6.1.57 Edge - 6.5.6 -> 6.5.7 Config refreshed using rewrite-kernel-config 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] All patches apply fine, builds fine, and seems to work fine as well. Checklist: [ ] My code follows the style guidelines of this project [ ] I have performed a self-review of my own code [ ] I have commented my code, particularly in hard-to-understand areas [ ] I have made corresponding changes to the documentation [ ] My changes generate no new warnings [ ] Any dependent changes have been merged and published in downstream modules View the full article

Description We still have some weird kernel versions, for x13s, media and some 32b that should be addressed in some way. They sits on 6.2 and 6.3 so we need to keep some conditions. Also patch for 6.5 is deprecated since today. Ref: https://github.com/armbian/build/pull/5697 How Has This Been Tested? [x] Few manual runs Checklist: [ ] My code follows the style guidelines of this project [ ] I have performed a self-review of my own code [ ] I have commented my code, particularly in hard-to-understand areas [ ] I have made corresponding changes to the documentation [ ] My changes generate no new warnings [ ] Any dependent changes have been merged and published in downstream modules View the full article

Description Bump kernels. Without this bump, EDGE breaks due to rtw88 patch issue. How Has This Been Tested? [x] Patching doesn't break View the full article

Description Bumped legacy, current and edge kernel. Legacy - 5.15.127 -> 5.15.130 Current - 6.1.47 -> 6.1.51 Edge - 6.5 -> 6.5.1 Fixed compilation of xradio and as its working fine, disabled cw1200 driver that I added for edge last week. Refreshed kernel configs. Also uwe5622 patches needed for orange pi 3 lts were not being applied as least kernel version was set to 6.0. Moved it back to 5.15. Not sure if it works though will test next week once I receive my orangepi 3 lts. Also for edge kernel, enabled rtw88 based drivers and disabled their corresponding legacy counterparts. 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] Tested all images on NanoPi Duo2 (sun8i H3) [X] Tested all images on Orange Pi Prime (sun50i H5) [X] Tested xradio drivers on Orange Pi Zero Checklist: [ ] My code follows the style guidelines of this project [X] I have performed a self-review of my own code [ ] I have commented my code, particularly in hard-to-understand areas [ ] I have made corresponding changes to the documentation [X] My changes generate no new warnings [ ] Any dependent changes have been merged and published in downstream modules View the full article

I am trying to get a RPi camera (imx219) working on a RockPI 4C. I have been piecing together DTS files from various places trying to make sense of it, and I noticed that the rkisp kernel module isn't compiled on the Rockchip64 kernels. Is there a reason for this or am I missing something? Looking at the kernel menuconfig, only one of its dependencies isn't compiled: `V4L_PLATFORM_DRIVERS=n`.

Description Enabled CONFIG_MT7915E on all kernels. Requires corresponding firmware to work https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/mediatek Jira reference number AR-1817 https://armbian.atlassian.net/browse/AR-1817 [x] My code follows the style guidelines of this project [x] I have performed a self-review of my own code [ ] I have commented my code, particularly in hard-to-understand areas [ ] I have made corresponding changes to the documentation [ ] My changes generate no new warnings [ ] Any dependent changes have been merged and published in downstream modules View the full article

Description Legacy - 5.15.123 -> 5.15.124 Current - 6.1.42 -> 6.1.43 Edge - 6.4.7 -> 6.4.8 Toggled CONFIG_RCU_TRACE in linux-sunxi-current.config to fix booting on 32-bit kernel 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] Booted legacy, current and edge images on Orange Pi Prime (sun50i H5) [X] Booted legacy, current and edge images on NanoPi Duo2 (sun8i H3) Checklist: [ ] My code follows the style guidelines of this project [ ] I have performed a self-review of my own code [ ] I have commented my code, particularly in hard-to-understand areas [ ] I have made corresponding changes to the documentation [X] My changes generate no new warnings [ ] Any dependent changes have been merged and published in downstream modules View the full article