Stephen Graf

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.

@SteeMan Thanks for the update. Please excuse me for being confused. I am looking at things like an end user would to determine board status.

Why am I seeing this: https://www.armbian.com/orange-pi-zero-2/ Maintainer needed?