Stephen Graf

@bryan_bennett Thank you for testing and for your comments. I am starting to work on putting together a pr for Armbian. It might take a while. There is a problem with analog audio on Pulseaudio. It seems that if you open the Pulseaudio volume control, the analog audio starts to play at a higher speed. This does not happen with HDMI audio. It also does not happen if one controls audio with the app audio controls, eg + - on mpg123.

@ER Samson I'm sorry to hear that you are still having problems. However as I mentioned to @Joko Christian, the applications you are running are not Debian or Armbian supported. I would recommend you try support from the individual software suppliers.

@Joko Christian I am not sure that mixing versions of firmware and kernel versions is advisable. I took note from @ER Samson that when he removed cloudfare and replaced it with an equivalent package, the problems went away. I am not able to do much with your issue as cloudfare is not part of Armbian, nor of debian for that matter. I would recommend you try the most recent current Armbian package and the latest release of cloudfare. Try to run without making changes to the firmware unless you need extra drivers for hardware that is not supported by the Armbian system as built.

@Joko Christian I can't find any archive for armbian-firmware. It might be built right into the image. Have you tried to install an older image? Have you looked at @ER Samson post above. He seems to be running the same PIHole and has some work arounds. Have you looked at top to see what is running to cause a hot cpu?

@sakesm Thank you for the update. I don't have a lot of experience with audio either. Usually it just works. With mpg123 you can adjust volume with the + and - keys, which I think do not cause any problems.

@sakesm Yes i came across that also. Can you confirm that it only happens on analog audio and not on HDMI and when using pulseaudio. I also tested with mpg123 and did not have problems using the mpg123 built in volume controls.

@Joko Christian For the archive, go to the image download page for the orangepione and look at the line just below the image icons. It would be very useful to know how your system is failing. Could you describe what is running on the machine at the time it fails? Please provide output of: sudo armbianmonitor -u

@sasa I tested with your patch and it gets rid of the error but also creates a new sound device. ahubdam, that has no input or output. I then just took the device creation out of the dtb and then there is no error even without the patch. Analog and HDMI audio still work. This is the piece removed from the dtb. ahub_dam_mach { compatible = "allwinner,sunxi-snd-mach"; soundcard-mach,name = "ahubdam"; status = "okay"; phandle = <0x3f>; soundcard-mach,cpu { sound-dai = <0x0e>; }; soundcard-mach,codec { }; };

@SUPA The warpme patches need work to implement into Armbian. That is what I have been trying to do. When and if we get it right, they should be included into the Armbian system. In the meantime clone my repository, which has the patches implemented, and build your flavour of system from there. cd ~/ git clone https://github.com/stephengraf/armbian_build_sg.git cd armbian_build_sg ./compile.sh The HDMI sound should work immediately. The analog needs to be enabled as @sasa suggested: /usr/bin/amixer -c 0 set 'Left Output Mixer DACL' 100% unmute /usr/bin/amixer -c 0 set 'Left Output Mixer DACR' 100% unmute /usr/bin/amixer -c 0 set 'Right Output Mixer DACL' 100% unmute /usr/bin/amixer -c 0 set 'Right Output Mixer DACR' 100% unmute

@sasa Many thanks for pointing out that analog sound just has to be enabled! I just tested and it works. I was dreading trying to debug kernel code when I should have been looking at the fundamental "is it turned on?" I will try the patch to remove the other sound error. As to automatic detection, yes on my orangepizero3 with H618 Allwinner SOC, HDMI detects the monitor and sets the proper resolution.

@SUPAThere is a lot more to building a system than just the kernel. That is what Armbian tries to do for you. I recommend that you use the Armbian build system. You should be able to build the system that you want. The audio patches do include analog audio, but to date there is still a problem and it does not start up. The armbian-config procedure has options to load kernel headers and also source.

@SUPA Thank you for testing the patch. I assume it worked and that you are working with an orangepisero3. If you want to build you own images follow the directions in the Armbian build manual: https://docs.armbian.com/Developer-Guide_Build-Preparation/ and clone my repository. Unfortunately I have limited space on my google drive. git clone https://github.com/stephengraf/armbian_build_sg.git

Yes I have tried the Zunlong images for orangepizero3 and they work. Unfortunately those images are for a Linux 6.1 kernel and the zero3 and 2w were only officially implemented into linux with 6.6. The challenge is to get the Zunlong code into Armbian with the newer kernels.

@ag123, @c0rnelius, and anyone else that has interest in sound on these devices. I have been able to put together a patch that enables audio for H161/H618 devices. So far only audio on HDMI works. Analog audio is still generating an error on startup. The patches were taken from a git repository by warpme: https://github.com/warpme/minimyth2/tree/master/script/kernel/linux-6.6/files , and probably came from the Zunlong SDK. A lot of the code was written by Allwinner. @pixdrift generated a version of the patches for Armbian and I continued to work on them. I have built a few images and have a git repository if anyone would like to test, particularly on boards other than orangpizero3, on which I have tested. zero3 desktop: https://drive.google.com/file/d/1jIMTIqKc6y_uuG7lRyXXhIWQ_fvo0XgI/view?usp=drive_link zero3 server: https://drive.google.com/file/d/1r-yn-ooeYoz1yROEJ-yx01_KhErKN_p8/view?usp=drive_link zero2 server: https://drive.google.com/file/d/1XQ9zzw_Bz-rZancDWuzGwMjHHn_4U8SE/view?usp=drive_link repository: https://github.com/stephengraf/armbian_build_sg.git There is another repository mentioned in the Armbian Forum: https://github.com/NickAlilovic/build If anyone has interest and skills to debug the analog audio, the dmesg errors are: [ 7.125509] ahub_dam-snd-soc-dummy-dai: substream ahub_dam-snd-soc-dummy-dai has no playback, no capture [ 7.125539] sunxi-snd-mach soc:ahub_dam_mach: ASoC: can't create pcm ahub_dam-snd-soc-dummy-dai :-22 [ 7.125780] sunxi-snd-mach: probe of soc:ahub_dam_mach failed with error -22

Have you tried switching the roles of your Ethernet devices to see if your VPN works on the other port?

Good luck.

It might also be a good idea to test with another know good Ethernet cable.

@klaute I did a quick check with my test orangepione and could not replicate your problem. I tested with 100Mbs and 1Gbps Ethernet switches. Welcome to Armbian 24.2.1 Bookworm with Linux 6.6.16-current-sunxi root@orangepione:~# ip addr 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host noprefixroute valid_lft forever preferred_lft forever 2: end0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 02:81:b1:07:76:5e brd ff:ff:ff:ff:ff:ff inet 192.168.1.24/24 brd 192.168.1.255 scope global noprefixroute end0 valid_lft forever preferred_lft forever inet6 fe80::4834:c56a:be43:e99e/64 scope link noprefixroute valid_lft forever preferred_lft forever root@orangepione:~# ip addr 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host noprefixroute valid_lft forever preferred_lft forever 2: end0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000 link/ether 02:81:b1:07:76:5e brd ff:ff:ff:ff:ff:ff inet 192.168.1.24/24 brd 192.168.1.255 scope global noprefixroute end0 valid_lft forever preferred_lft forever inet6 fe80::4834:c56a:be43:e99e/64 scope link noprefixroute valid_lft forever preferred_lft forever root@orangepione:~# ip addr 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host noprefixroute valid_lft forever preferred_lft forever 2: end0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 02:81:b1:07:76:5e brd ff:ff:ff:ff:ff:ff inet 192.168.1.24/24 brd 192.168.1.255 scope global noprefixroute end0 valid_lft forever preferred_lft forever inet6 fe80::4834:c56a:be43:e99e/64 scope link noprefixroute valid_lft forever preferred_lft forever From your logs it would seem that your Ethernet port is not connected. Can you verify. ### ip addr: 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet XXX.XXX.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host noprefixroute valid_lft forever preferred_lft forever 2: end0: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 02:81:1f:4d:3f:5b brd ff:ff:ff:ff:ff:ff I do not understand your comment "If I disconnect it, from a normal operating switch, the OpiOne’s behavior looks the same." Is your "normal" something different than in the failure mode? What is "looks the same"? When you unplug the network can you still interact with he serial port?

For a quick test I ran sbc-bench every 20 minutes overnight, about 11 hours. The system is still running well. See the attached log. sbc-bench v0.9.65 Xunlong Orange Pi.txt You might want to connect to the serial port logged in as root to see if it is available after a system hang. There may be some messages.

@SteeMan Yes it is. I just found it also. After reading those posts I loaded ubuntu 23.10 with kernel 6.5 and am having success creating images. Can you add my posts to the other thread? What changed a few days ago to cause this? I had been using the official ubuntu build for months without ant changes of snags.

Yesterday I started to have problems using the build environment. Any build I have tried fails with something as shown below. (https://paste.armbian.com/noloqaquqo) Today I updated vbox, reinstalled ubuntu git cloned master and tried again with the similar results (different loopx sometimes). Any help would be greatly appreciated. 🔨] The partition table has been altered. [🔨] Syncing disks. [🌿] Allocated loop device [ LOOP=/dev/loop3 ] [🔨] Error: Partition(s) 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64 on /dev/loop3 have been written, but we have been unable to inform the kernel of the change, probably because it/they are in use. As a result, the old partition(s) will remain in use. You should reboot now before making further changes. [💥] Error 1 occurred in main shell [ at /home/sysadmin/build/lib/functions/logging/runners.sh:211 run_host_command_logged_raw() --> lib/functions/logging/runners.sh:211 run_host_command_logged() --> lib/functions/logging/runners.sh:193 prepare_partitions() --> lib/functions/image/partitioning.sh:230 do_with_logging() --> lib/functions/logging/section-logging.sh:81 build_rootfs_and_image() --> lib/functions/main/rootfs-image.sh:86 full_build_packages_rootfs_and_image() --> lib/functions/main/default-build.sh:36 do_with_default_build() --> lib/functions/main/default-build.sh:42 cli_standard_build_run() --> lib/functions/cli/cli-build.sh:25 armbian_cli_run_command() --> lib/functions/cli/utils-cli.sh:136 cli_entrypoint() --> lib/functions/cli/entrypoint.sh:176 main() --> compile.sh:50 ] [💥] Cleaning up [ please wait for cleanups to finish ] [🌿] Unmounting recursively [ SDCARD - be patient ] [🌿] Unmounting recursively [ MOUNT - be patient ] [🚸] Freeing loop [ trap_handler_cleanup_rootfs_and_image /dev/loop3 ] [🌿] Freeing loop device [ /dev/loop3 ]

I have used the old /sys/class gpio interface quite extensively in the past. However it is not available in the newer kernels and my only experience with the new api has been to test the orangepizero3 with the code in the links below. It worked. https://docs.rs/gpio-cdev/latest/gpio_cdev/ https://github.com/rust-embedded/rust-gpio-cdev

@Roberto I think the /sys/class type of gpio is no longer supported in the new linux releases. I have not used python to control gpio but when I tested gpio on the zero3 I discovered that the /sys/class procedures no longer worked. I then looked up some rust code and used their examples to test using the /dev/gpiochip procedures. I am sure that there must be some uptodate python code.

This works on my orangepione. I think dtc comes with the standard image. Armbian-unofficial 23.11.0-trunk Bookworm with bleeding edge Linux 6.6.1-edge-sunxi sysadmin@orangepione:~$ nano screen.dts sysadmin@orangepione:~$ dtc -I dts -O dtb -o screen.dtbo screen.dts sysadmin@orangepione:~$

What are you booting from? I use an SD card with the up to date image which works just fine. There is no boot partition in the image, just a boot directory. Can you try an up to date image with and SD card? The fel firmware would be part of u-boot that is on the Armbian image.