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!

Hello, I find armbian awesome and my problem is because of the manufacurers. I basically want to play accelerated video (because I need 4k). I tried amlogic, but it is not still supported (https://linux-meson.com/hardware.html) the status is partial for the chips I tried. I don't what "partial" means but I can hardware decoding. I also tried allwinner, several chips. In this page https://linux-sunxi.org/Sunxi-Cedrus I see that it is supported but I tried with new kernels, old kernels... Nothing worked. I always reach a point that stops me (like segmentation fault when loading sunxi modules, system freeze when using vdpau, compilation errors due incompatibility between version...) I was thinking of try some rockchip but I think that I will suffer the same pain so this is why I want to ask you guys because I am a bit lost and I am starting to think that everything I try is worthless. Can someone bring me some light? Any tip about what chips are more "friendly" with video acceleration and, if mainline kernel or not, player to use... All the documentation/posts I found are outdated or incomplete and this is the reason I am writing this post, because I am not able to find more information. I know that the manufacturers does not help and everything we have is due the awesome work of the community. It is complicated stuff. Any kind of information will be very helpful. Thanks

Hi, to my side same: root@helios64:~# cat /var/log/syslog | grep mdadm root@helios64:~# and, for moment not crash/freeze to my helios64...

nightly kernel? I think you are talking about nightly releases that are not yet stable or tested. Unfortunately I don't have time to test kernels and wait for any bugs.

Hi, This morning, i do cold boot and crash after few minutes (less than 10min...) Boot is okok but lose ssh connection and to same with usb wire console, i have login and password ask but then i am block... (i can't find if problem hardware... systemd... software...) I use reset bottom and after 15min uptime, i try the same and not lose connection, (i don't understand why not lose connection, i do nothing and Helios64 seem Okok...) i do: (3 times) root@helios64:/tmp# ./cpufreq-switching allocated 64MB test: toggle freq before write 99/100 test: toggle freq before read 9/10, 99/100 root@helios64:/tmp# ./cpufreq-switching allocated 64MB test: toggle freq before write 99/100 test: toggle freq before read 9/10, 99/100 root@helios64:/tmp# ./cpufreq-switching allocated 64MB test: toggle freq before write 99/100 test: toggle freq before read 9/10, 99/100 root@helios64:/tmp# Not crash/freeze and during this test, i have samba Time Machine backup work and lot of I/O Network and 1GO of data pass from my mac to helios. I don't tune voltage, juste use 6.6.28 Kernel and my standard configuaration.... I run again you program and, i have again Time Machine Backup (samba share in background): | | | | ___| (_) ___ ___ / /_ | || | | |_| |/ _ \ | |/ _ \/ __| '_ \| || |_ | _ | __/ | | (_) \__ \ (_) |__ _| |_| |_|\___|_|_|\___/|___/\___/ |_| Welcome to Armbian-unofficial 24.5.0-trunk Bookworm with Linux 6.6.28-current-rockchip64 No end-user support: built from trunk System load: 86% Up time: 27 min Local users: 2 Memory usage: 11% of 3.77G IP: 10.0.0.155 CPU temp: 41°C Usage of /: 47% of 14G RX today: 1.5 GiB [ General system configuration (beta): armbian-config ] Web console: https://helios64:9090/ You have no mail. helios64@helios64:~$ su - Mot de passe : root@helios64:~# cd /tmp/ root@helios64:/tmp# uptime ; ./cpufreq-switching ; uptime 06:34:39 up 28 min, 3 users, load average: 5.87, 4.75, 3.61 allocated 64MB test: toggle freq before write 99/100 test: toggle freq before read 9/10, 99/100 06:36:12 up 29 min, 3 users, load average: 4.99, 4.71, 3.70 root@helios64:/tmp# No Problem, To conclude for moment, to my side; 6.6.28 stable but not at cold boot... stable after. Something (hardware or software) when cold boot crash or do bug in linux software... and after reset buttom is Okok... It's crazy i know ! (Possible problem in cold ramlog boot is /var/log full... i view is full just now... i will investigate next week...) If you want next week, i build a Vanilla armbian from source with official framework and run your cpufreq-switching on it, i think i will have same this day with my standard configuration but maybe not with crash at cold boot If you read my history message about Helios64 since about 3 years... it never stable with standard parameter. I do many tests and to change Kernel and this day the Best Kernel i never use is 6.6.27 and upper because not crash at standard frequency Schedutil Governor The very bad Kernel was 6.X branch, with thing kernel, Helios crash often just when i unlock my raid10 with LUKS cryptosetup And le 5.15.(something)69 or just before was the best stable Kernel with 400-1400Mhz schelutil (i speak about this in very old post) I try again you program, Time Machine Backup is finish... root@helios64:/tmp# uptime ; ./cpufreq-switching ; uptime 06:51:25 up 44 min, 3 users, load average: 3.98, 4.58, 4.24 allocated 64MB test: toggle freq before write 99/100 test: toggle freq before read 9/10, 99/100 06:53:01 up 46 min, 3 users, load average: 3.03, 4.09, 4.10 root@helios64:/tmp# Not crash, now i go to work office and then pass a weekend with my familly, keep in touch next week During this weekend, i run on my helios64 a script do in loop: echo check > /sys/block/md0/md/sync_action and: btrfs check --readonly --check-data-csum --progress /dev/disk/by-uuid/1d4e2c84-1c43-4d73-8acb-XXXXXXXXXXXXXX If Monday morning when i back my Helios64 not crash/freeze, for me 6.6.28 is good Kernel. Have a good day

Orange Pi 5 plus. It seems that in the 'edge' kernels, ssh is disabled by default. Since HDMI doesn't function this is a problem. I used the debugging UART and after setup I got the message "ssh.service is disabled" I enabled the service and all is well. Any reason why ssh would be disabled?

Ok, upgraded successfully. I said no to removing obsolete stuff in the end and it seemed to want to delete armbian stuff. I did not freeze the kernel this time one thing is a bit weird Now it says Armbian 23.02.2 Jammy shouldn't the version be 24. something? I am nearly done, let me know if I can safely run apt update/upgrade? I'd really hate to start over. My /etc/apt/sources.list.d/armbian.list file contents - the directory was a bit different Thank you all so far!

Yes, in the very end I was asked to remove obsolete packages. I said yes all the times. I don't remember what was in the list, since it was about 76~ packages I may try with no option to keep them Is there any way to enforce this manually pre-upgrade? I only freeze the kernel, i suppose it is something different? Or maybe I can try to upgrade without freezing kernel? Or is that a guaranteed fail?

Hi everybody, I test 24.05 trunk build myself armbian bookworm with 6.6.27 Kernel and... For moment, i have a stable Helios64 with 400-1800Mhz schedutil and just my tuned fancontrol file. Running for more than 1 days without crash with my test pattern... and not crash/freeze until now !!!!!! I hope not crash during next few days... If not crash, i advise everybody to swith to this kernel Keep in touch

Since I am interested in the connection ability, I figured the info we gather should go into ONE thread. I have tried to build new kernels, but can only see USB controllers and devices two ports. I have seen a lot of work by Sebasitian Reichel @ Collabora, and his patches, but these do not seem to have the desired result on my test board. Orange PI 5. There seems to be an issue with the port mux, FUSB302, that either connects the last USB to the "vertical" port or to the "USB C" connector. I will comment my findings and attempts to correct this in this thread, and think we could find out where we are if you add your findings, successes and failures, rather than cluttering everywhere Regards, Gullik

Ok, I repeated the update of bullseye to bookworm. But I did not apt upgrade (only apt update) from the bookworm armbian repository, which installed these packages last time armbian-bsp-cli-odroidn2 armbian-config armbian-zsh base-files linux-dtb-current-meson64 linux-image-current-meson64 linux-u-boot-odroidn2-current Instead I used armbian-config to switch kernels. This also updated the uboot, I think. U-Boot 2022.10-armbian (Feb 23 2024 - 10:32:33 +0000) odroid-n2/n2-plus And now it boots, monitor shows the startup and login does work: ___ _ _ _ _ _ ____ / _ \ __| |_ __ ___ (_) __| | | \ | |___ \ _ | | | |/ _` | '__/ _ \| |/ _` | | \| | __) || |_ | |_| | (_| | | | (_) | | (_| | | |\ |/ __/_ _| \___/ \__,_|_| \___/|_|\__,_| |_| \_|_____||_| Welcome to Armbian 24.2.1 Bookworm with Linux 6.6.16-current-meson64 # lsb_release -a No LSB modules are available. Distributor ID: Debian Description: Armbian 24.2.1 bookworm Release: 12 Codename: bookworm # uname -mrs Linux 6.6.16-current-meson64 aarch64 # cat /etc/debian_version 12.5 Boot log now shows: U-Boot 2022.10-armbian (Feb 23 2024 - 10:32:33 +0000) odroid-n2/n2-plus Model: Hardkernel ODROID-N2 SoC: Amlogic Meson G12B (S922X) Revision 29:c (40:2) DRAM: 3.8 GiB Core: 388 devices, 27 uclasses, devicetree: separate MMC: sd@ffe05000: 0, mmc@ffe07000: 1 Loading Environment from nowhere... OK In: serial Out: serial Err: serial Board variant: n2-plus Net: dwmac_meson8b ethernet@ff3f0000: Can't get reset: -2 eth0: ethernet@ff3f0000 Hit any key to stop autoboot: 0 starting USB... Bus usb@ff500000: Register 3000140 NbrPorts 3 Starting the controller USB XHCI 1.10 scanning bus usb@ff500000 for devices... 3 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Device 0: unknown device switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found U-Boot script /boot/boot.scr 8147 bytes read in 2 ms (3.9 MiB/s) ## Executing script at 08000000 U-boot default fdtfile: amlogic/meson-g12b-odroid-n2-plus.dtb Current variant: n2-plus For variant n2-plus (dash version, 2021.07 or up), set default fdtfile: amlogic/meson-g12b-odroid-n2-plus.dtb 161 bytes read in 2 ms (78.1 KiB/s) Current fdtfile after armbianEnv: amlogic/meson-g12b-odroid-n2-plus.dtb Mainline bootargs: root=UUID=efa55279-3372-4eee-9c23-7b26c477cfb0 rootwait rootfstype=ext4 splash=verbose console=ttyAML0,115200 console=tty1 consoleblank=0 coherent_pool=2M loglevel=1 ubootpart=210296a2-01 libata.force=noncq usb-storage.quirks=0x2537:0x1066:u,0x2537:0x1068:u cgroup_enable=memory swapaccount=1 16364304 bytes read in 698 ms (22.4 MiB/s) 28346880 bytes read in 1208 ms (22.4 MiB/s) 80112 bytes read in 7 ms (10.9 MiB/s) 232 bytes read in 5 ms (44.9 KiB/s) Applying kernel provided DT fixup script (meson-fixup.scr) ## Executing script at 32000000 ## Loading init Ramdisk from Legacy Image at 13000000 ... Image Name: uInitrd Image Type: AArch64 Linux RAMDisk Image (gzip compressed) Data Size: 16364240 Bytes = 15.6 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 04080000 Booting using the fdt blob at 0x4080000 Loading Ramdisk to 3f064000, end 3ffff2d0 ... OK Loading Device Tree to 000000003efe8000, end 000000003f063fff ... OK Starting kernel ... So everybody - thanks!

My final comment in this thread (unless something USB related comes up) USB works fine for me, and I have tested it with hub's and my own usb-device design. Also, kernels are now at 6.8.5 build.417, and boot just fine. Regards, Gullik

A very worthwhile discussion indeed now that there seems to be some light being seen at the other end of the tunnel. I'm not so sure that the specific USB hardware support is now in place in it's entirety. For the past few days I have been testing all of the rolling releases for both 6.1 and 6.8 kernels and the results can differ from day to day. I fully understand that the nature of rolling releases is that there are all manner of changes made from day to day, so no complaints at all as I know that things can break. The fact that we do know that the USB hardware support does now have solutions does bode well and I would imagine that it will integrate into all builds very soon. In terms of the transitioning, pitfalls and remedies, I have come across an issue with a particular build type. This week I spotted a build that was of particular interest because of the panthor and amazingfated connections , the Orangepi5_jammy_vendor-boogie-panthor_6.1.43_kde-neon-amazingfated-oibaf_desktop.img, which is now at Armbian_24.5.0-trunk.416. Unfortunately I am unable to get it to load from any trunk build. It initially boots correctly and I go though the config routine to create login and passwords etc. But when things get to the actual desktop login screen, when logging in, the screen goes briefly black, with the mouse cursor popping up and a small white bar at the top left of the screen, before being returned to the login screen. No matter how many times I try, it will not complete the login process. I know that the password is correct because if I deliberately enter an incorrect password, it is rejected with a specific message to conform this. I did then attempt to login as root but even when entering the correct credentials created during the initial config process, the credentials were rejected as being incorrect, despite them being correct. Hopefully somebody else may have tested the same and can offer a potential solution to enable me to fully test and report back on this particular 6.1 build.

armbian.list: deb http://mirrors.dotsrc.org/armbian-apt/ bullseye main bullseye-utils bullseye-desktop armbian-config says "No other kernels available"

I upgraded from my own-compiled Armbian kernel 6.8.0-rc5 to 6.8.4 and there are now very annoying stall when for example I drag a KDE Konsole window. Also when I play a 1080p50 HEVC video, as son as a move the mouse, the whole video stalls. Besides 6.8.0-rc5, the normal apt provide 6.8.1-edge-rockchip-rk3588 also works OK. 6.8.5 has the same issue as 6.8.4. As indicated, I use KDE, X11, compositor disabled. Enabled makes no difference. OS base is Armbian Bookworm, but I have also used kernels 6.8.1 and 6.8.4 with a rootfs copied from an RaspberryPiOS and Opensuse-Tumbleweed. RPiOs is also Debian Bookworm, Tumbleweed is latest, KDE6. So it is not KDE6. KDE Wayland leaves black screen still (doesn't work), but that is not a showstopper. Is anyone else experiencing the same? PS: I run mainline as the vendor kernel 6.1.43 fails on running KVM (some tag of the Cortex-A55 is unknown) so qemu-KVM don't work/start and running VMs is a key use-case I bought the NanoPi-R6C for.

Hello, Yes i set fixed frequency to 1200. For power consumption, i my case off use it's not a problem because i start when use it and stop helios64 when i don't use. My big problem isn't unstability during long time but during intense use. For example: 400Mhz - 1400mhz is okok if helios do nothing... but when fast i/O network or Disk I/O, Helios64 crash or freeze. With 5.1X Kernel, Helios is stable at 400-1400MHZ Schedutil With first 6.X Kernel, Helios is stable at 400-14000MHZ Schedutil With 6.6 Kernel and upper my pattern to test stabilty crash when i use setting above and not crash with 1200 Fixed frequency. At 1400 or more with my pattern to test Helios crash. My configuration is: 8To x 4 Raid 10 -> LVM -> Lucks -> LVM -> BTRFS. To test stabilty i do: - Scrubbing RAID and at same time i do a BTRFS with Checksum check, that do a lot of I/O and Frequency change... Since i pass to Kernel 6.6.X, this pattern to test fail always. With 5.1X Kernel 400-1400MHZ Schedutil and 6.X Kernel 400-14000MHZ Schedutil and at 1200 Fixed, always pass and always crash at 400-1200MHZ. I advise you if you want stable online setting to Keep a 5.1X Kernel with 400-1400MHz. That not my choice because i prefer to follow most update Kernel and i believe (or dreaming) adevelloper find problem with Helios RockChip and correct it one day.

Hey, if this works for you just fine then there is not much to worry about. Consider either freezing firmware via armbian-config or create a backup of your OS before doing major updates like kernel since those nightly images feed themselves from the beta repository. Anyway you are free to build your own image using the build framework. Check the documentation, for standard images there isn't much to it. https://docs.armbian.com/Developer-Guide_Build-Preparation/ https://docs.armbian.com/Developer-Guide_Welcome/ In terms of kernel choice there isn't a perfect solution yet. Both legacy and vendor are, as their names imply, aged vendor bsp kernels which support most board functions but on the downside won't receive much attention in future. On the other hand there is edge which follows mainline as close as possible but is under heavy development to add missing board features and until completion, if this state is ever reached anyways, will take years at least. Basic functionality is there and its mostly fine for server tasks.

Thanks. With the log level higher, the freeze is on: zram0: detected capacity change from 0 to941376

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

Dear Armbian Community, We’re thrilled to announce that Armbian development is currently at full throttle, with significant improvements to our build framework and daily bug fixes. Our community of regular contributors has grown, and we’re witnessing increased utilization of the build framework. Here are some highlights of what’s been happening lately: Framework Enhancements: We’ve been diligently working on enhancements to our build framework, focusing on areas such as kernel config management, libc generation, kernel debugging, and kernel security checks. Hardware Support: In collaboration with Sinovoip, we’ve added new platinum supported hardware which brings higher level of support. In collaboration with Radxa, we’ve integrated the new Zero 3E/3W boards into our build framework, expanding our hardware support. Additionally, we have several boards in staging: Bananapi M4 Zero, Rock S0, and several community added targets: Orangepi Zero 2W, FriendlyElec CM3588 NAS, X96 Mate TV Box. Home Assistant Integration: We’ve incorporated additional fixes for Home Assistant, further enhancing Armbian-powered Home Assistant deployment. Updated images with these fixes have been released. If you encounter any issues, please report them here. Rockchip Kernel Updates: Following recent upgrades of Rockchip vendor kernels, the entire Rockchip family now benefits from the first open-source panthor driver implementation. While this marks significant progress, it’s important to note that these images are experimental and may contain bugs. Download them from the board download pages under “Daily/Rolling releases from CI pipeline.” Code Review Initiative: In light of recent incidents, such as the backdoor discovered in a widely used open-source tool (xz), we recognize the importance of robust code review processes. We’re actively seeking community members who can contribute to improving our code review practices. If you’re passionate about open-source and want to make a difference, consider applying to become a code reviewer here. Thank you for your continued support and contributions to the Armbian project. Together, we’re building a stronger, more secure open-source ecosystem. Warm regards, The Armbian Team View the full article

How do you build it? I have been using the "standard build procedure", and I only get an option to build standard, vendor or edge kernels, edge seems to be 6.8.4. Where do I modify for a different kernel git url? I could well spend the work and effort.... Gullik

Hi all, reporting a regression in new Armbian 24.2.1 kernel version. New kernel is causing Orange Pi 4 LPS not to boot most of the time, when it boots, then there is no network. Kernel hangs with oops errors on the screen, and all debugging stuff. Sorry that I did not caught any of them on my phone, but it would have been incomplete anyway. How to reproduce: Install any 24.2.1 based system on Orange Pi 4 LTS Upon first boot, you will have issues. No Ethernet network. Second boot will most likely not succeed no matter what you do and system will brick permanently, by not booting at all (no video output), or booting and then showing kernel crash. I've tested: Armbian_24.2.1_Orangepi4-lts_jammy_current_6.6.16_xfce_desktop.img.xz (system booted into desktop only once, never managed to do it again. No network in first boot) Armbian_24.2.1_Orangepi4-lts_jammy_current_6.6.16.img.xz (kernel crash in terminal on second boot, no network on first boot) Armbian_23.8.1_Orangepi4-lts_bookworm_current_6.1.50.img.xz - here I installed older image, all was good, network good, reboots good, so I upgraded all packages, upon restart everything was broken again) Armbian_23.8.1_Orangepi4-lts_bookworm_current_6.1.50.img.xz - formatted the card again, got it working again, I went to armbian config tool and marked Armbian kernel packages to freeze, not going to upgrade them unless regression is confirmed to be gone. Notes: I've tested this with nothing connected to the board except for HDMI cable and some GPIO pins. Nothing on USB etc. New kernel 6.6.16. on Armbian 24.2.1 is experiencing this regression. Kind regards

I've got an OrangePi based on the Rockchip RK3399. The official OrangePi Debian version I'm using is Armbian-based I believe and uses a 5.10 kernel. I want to upgrade the kernel as later ones support some video features of the RK3399 I want to use. The problem is, if I build the kernel using the standard vanilla method from kernel.org sources even using the same config file from the running kernel without changing anything (make olddefconfig), the device won't boot when I symlink the new kernel to /boot/Image. Interestingly, it does boot if I symlink the new initrd to /boot/uInitrd, but only with the old kernel. Is there something special I need to do to the kernel that Armbian expects? Are there required secure keys or anything that u-boot expects that aren't in my new kernel? I thought the problem might be missing kernel patches, but as far as I know RK3399 support is mainlined already, so new kernels should support it. Any help is appreciated!

New 6.x based kernels for OPI 4 LTS seems to be a hit or miss for HDMI monitors. Some work, and others especially TVs dont output video at all. Images with 5.15.x kernels dont have this issue.

@Netraam31 I did a quick check on a board with rk3328 (not rk3318, but should be the same) and you can use both the USB2 OTG port or the USB3 port as peripheral. in the device tree the device usb@ff580000 is the USB2 OTG port controller and usb@ff600000 is the USB3 port controller. I quickly tried ethernet gadget to check if it works. This command loads the USB ethernet gadget module. which is a bit of "deprecated" in favor of configfs, but it is handy for tests (run it with the USB cables connected): modprobe g_ether iSerialNumber=0x00000001 Then a device usb0 should spawn on both the machines, which is nothing more and nothing less than a regular network interface. You have to give an address to both the endpoints and then you should be able to ping and exchange data. The result is that, at the current state of the kernel 6.1 I have right now (but 6.6 is exactly the same, since nothing changed), the USB 3.0 port is working plenty well, instead the USB 2.0 port is suffering the same problems experienced for rk322x, which disconnection and system freeze. Things seems to have changed with kernel 6.8, where also the USB 2.0 ports seems to work, thanks to the upstreamed fix for clock gating. You should be able to upgrade to kernel 6.8 installing the linux-image-rockchip64-edge package or, more appropriately, via armbian-config. Don't forget to put kernel and dtb packages in hold if you modify them manually, otherwise updates will overwrite your modifications!