Stephen Graf

@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.

@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?

I would like to have a clear statement of how the orangepizero2 and orangepizrto3 are going to be treated going forward. Currently the orangepizero2 is a supported board, although how it got that way I can't figure out. So little of it was working until this round of development over the last few months. There is no maintainer listed at present. The only software differences between the zero3 and zero2 were taken care of upstream and are not an issue for Armbian. Other than the work to set up the orangepizero3 as a wip all the recent development work benefited the zero2 (a supported board) as much as the zero3. There was a lot of good work done that benefited a supported board. Any arguments to support or not the zero2 applies equally to the zero3. With the availability of the zero3, the zero2 is probably hardware obsolete. It is important for someone who is trying to choose a board for use to clearly understand what software support there is for the board. I probably made a mistake by assuming that because the zero2 was supported the zero3 would also be. There were volunteers willing and capable to make that happen. We were being supported by a developer. The zero3 is now much more ready to be a supported board than the zero2 ever was. If there is no possibility of this happening then the potential users of the zero3 need to be aware so that they can take that into consideration in going forward. Also there is no point for volunteers to work on the zero3 if developers are just going to ignore, or worse reject, the volunteers work. A clearer, if possible, statement would be much appreciated.

Igor fixed the problem that was probably part of the "glitch" on the last release.

@SteeManI would like to set up discussion on the overly topic. Should we continue here or start a new thread? I don't think we should be starting to write code until there is a reasonable agreement on how to proceed. We should also share our ideas instead of pushing them to a PR first thing. Recently @Gunjan Gupta posted this in the current PR he proposed. It has some good thoughts. We can start with this, see what can be done to make it smooth for the end user and minimize the work required by developers. I use armbian-config. I think anyone who takes part in this discussion should confess to whether they do.😊 "These are generic overlays, other examples are there in the existing patches and can be extracted from kernel source. There is no other documentation. There never was anything on any platform or OS that provides the behavior you are expecting to have. Even on raspberry pi running raspian, you can add all those hundreds of overlay in the config.txt file and other than maybe having trouble booting, no other kind of indication is given to the user. It was always left for the user to decide what overlays they want to enable, and it was always left to the user wits to determine whether overlay will have conflicts or not. I understand you want to make it as simple as possible for user to easily determine what overlays can conflict with other overlays. That part can not be implemented within overlay itself. Thats something that needs to be implemented in armbian-config. armbian-config also lacks one other thing, it doesn't tell users overlay parameters are there and what their values can be. So it is long due for the change. Here is a proposal for how this functionality can be implemented Extend armbian-config's hardware configuration to two different configurations i.e lets say one file is for SoC overlays listing all existing overlays that can be applied on that SoC, their corresponding parameters and the possible values for the same. Also mentions the overlays that can conflict with each other. Second config file will be board specific configuration file providing a list of overlays that can be used on that board. Then extend armbian-config to use that information and provide the behavior you are expecting user to get." Here are some of my current thoughts. It may be possible to provide a full list of overlays without modifying armbian-config. I am glad to see that @Gunjan Gupta has acknowledged that a board specific file could be used. There is an Armbian cli procedure that @Gunjan Gupta showed me that I think takes a dts and creates a dtbo and puts it in ArmbienEnv which will then load at boot time. I think a dts can have comment lines. If we created the dts files for the secondary overlays with suitable comments within the dts file that warned about possible conflicts, pins that the dts will use etc, and then put these files into the allwinner/overlay directory, it would give the more knowledgeable user the option to install the secondary overlay. The less savvy user could just use the primary overlays provided by armbian-config. This design would not require any work on armbian-config. The dts files for the secondary overlays would become the "generic" overlays. I am not sure how to get the secondary dts files into the allwinner/overlay directory, but hopefully this is a patch procedure. Any new dts files would require a patch anyway. I don't think it is necessary to go back and modify overlays for the existing SBC. Anyway, I am sure there are multiple solutions and this is possibly one for discussion.

I am sorry that you have to get personal in this discussion. Never have I suggested taking a shortcut. What I am striving for is simplification. There is a big difference between the two. I am also trying to improve the end users experience on Armbian, for without end users there would be no need for Armbian. Please stick to criticizing my suggestions and not me. Constructive criticism would be better as it is always more useful in the long run.

Unfortunately I don't think there has been any work on the TV out. Not even Zunlong supports TV out. From the Zunlong zero3 manual: Analog audio and video output interface Supported, it can be used to connect headphones to play music, or connect to TV through AV cable to output analog audio and video signals (Android system only). Using the main build for Armbian would thus be as good as any place to start.

I previously suggested and then retracted the idea of enabling out of the box. I do not think a separate PR is required to change PH5 to PH9. It should be done with overlays. My current thoughts are that the overlays should be set up to allow the end user the ability to enable and have working what is described on the picture shown in the previous post. That to me implies an overlay that enables spi1 and uses PH9 as a cs. There should also be an overlay that enables i2c3. If there were to be an overlay for spi1 with PH5 for a cs, then there would have to be a caveat that it will conflict with i2c3. I would prefer that this overlay be left as a user provided overlay as it would require additional knowledge on the end user to recognize that it was possible and that there is a potential conflict.

@Gunjan Gupta @pixdrift This is the data that most users would go by when trying to set up the orngepizero2/3. It clearly shows that the cs for spi1 is PH9. If one tries to enable both i2c3 and spi1 with the current dts one will get an error due to the conflict with PH5. If I only enable spi1 I will have an issue because I would expect cs to be on PH9 and not PH5. There is no reason to leave this kind of confusion uncorrected. My original solution was to put the change for cs to PH9 in the overlay that enables spi1. I have tested that. What is happening to the overlays? Yes it is possible to set up multiple uses for the SOC pins, but to keep things simple, the software should initially conform to what the diagram shows.