Stephen Graf

@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

@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
 

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

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.

Well I found it by asking for kernel configuration changes during the build setup.  I think the original values were 15 for 17 and 12 for 15 but I can't remember for sure.  Anyway with the new values I can see the beginning of the dmesg and journal does not report missing messages.
 
However the extra data did not show anything to help me with the bluetooth problem.
 
 
x               General setup  --->   
 
 x           (17) Kernel log buffer size (16 => 64KB, 17 => 128KB)                             x x
 x           (15) CPU kernel log buffer size contribution (13 => 8 KB, 17 => 128KB) 

@MrK I think you owe @Gunjan Gupta an apology.  There is no need for such language when people are volunteering their time and efforts, or ever for that matter.
 
@MrK you are in the wrong forum.  Changes such as you are proposing should be done at the Linux kernel level.
 
@MrK I am not sure the following comments are worth posting. But if it helps you, I would recommend that you learn to work with others in a team environment.  You will get more things done and with better results.  If you had been working for me I would have fired you for behaving this way. It is just too disruptive.

@pixdrift Would you please look at dmseg on your orangepizero2 to see if it starts at time 0.
 
I came across this in the internet:
 
Your kernel's ring buffer ran out and the first entries were removed for new entries.
Simply set CONFIG_LOG_BUF_SHIFT and CONFIG_LOG_CPU_MAX_BUF_SHIFT larger in your kernel config.
 
 
yeah now works with 19!
 
~ $ cat /usr/src/linux/.config | egrep CONFIG_LOG_
CONFIG_LOG_BUF_SHIFT=19
CONFIG_LOG_CPU_MAX_BUF_SHIFT=12

Orangepizero2/3 are using spi0 internally to connect to the 16MB flash memory on the boards.  Spi1 is available and should be enabled by a working overlay in the near future.
In the meantime if you can find the driver source, it should be easy to change the spi port and cs in the code as they are usually just definitions.
As an aside, if you are looking to use a tpm for secure boot, you should be looking at u-boot and not Armbian.

@MrK I think you owe @Gunjan Gupta an apology.  There is no need for such language when people are volunteering their time and efforts, or ever for that matter.
 
@MrK you are in the wrong forum.  Changes such as you are proposing should be done at the Linux kernel level.
 
@MrK I am not sure the following comments are worth posting. But if it helps you, I would recommend that you learn to work with others in a team environment.  You will get more things done and with better results.  If you had been working for me I would have fired you for behaving this way. It is just too disruptive.

@Gunjan Gupta Yes I can see that you are trying to take on too much and no I don't think this is that urgent. However in the interests of moving forward, is there anyone else who would have some cycles to deal with this?
 
I would like to follow your proposal and stay with the existing naming convention for the time being.  As the orangepizero3 is the first h618 SOC, in keeping with the existing procedures we should create a new overlay structure called sun50i-h618. I could recreate the patch for the overlays (5) that I think are useful for the zero3.  Then by the time new h618 boards are added you may have had time to revisit the whole issue.  In the meantime let others do the work.  This change will not impact any other board.
 
As I am proposing to stay with the existing procedures. I don't think this patch will require any significant time from you. I can see from @SteeMan comments that trying to improve things will be a big headache.
 
What do you think?

@ag123@Gunjan Gupta@pixdriftLet's try to go back to fundamentals to see what we are trying to resolve with the overlays.
 
I will try to give you an idea of what a hardware developer would think about when deciding on a specific SBC.  The SBC designer will have made some choices as to what i/o will be available on the board.  The SOC has numerous options of which only a few will be implemented.  The hardware developer will look at the array of boards available and choose one that readily provides the functions that he thinks he would need.  I chose the orangepizero3 based on the availability of i2c (aka twi), spi and gpio which is very similar to the orangepione that I have a lot of experience with.  My problem is trying to get this i/o enabled via the usual armbian-config procedure. @Gunjan Gupta has taught me how to write overlays and I have been able to patch the dtb directly to get the i/o working.  But that is not the preferred procedure.  In the process I have come to question the rational of tying the overlays to the SOC instead of the SBC.
 
Should the overlays for orangepizero3 be labelled sun501-h618? That would be an easy solution for today as there are no other h618 boards. I think the bigtree board should not have been allowed to use the label sun50i-h616 for its overlays as that board is a very specific implementation for a particular environment.
 
After further reflection I don't think enabling the i/o in the dtb is the best idea.  It is usually better to keep things turned off if not in use. @pixdrift Think of your problem with the half plugged in serial to usb adapter.  In a similar vein I would recommend that gpu, bluetooth, wifi and hdmi not be always enabled. Many users will run a headless server using these boards and all these unused devices add a lot of software overhead in addition to the extra power drain and associated heat generated.
 
I am not sure this moves us further along in resolving the issue, but I hope it provides some stimulus for thought.

@pixdrift  I built an image for the zero3 from your repository and I am not having any difficulties with the overlays.
 
If you think it is the overlays that are causing your boot problems you can try putting your system drive on another machine and removing the overlays line in:
 
sysadmin@orangepizero3:~$ more /boot/armbianEnv.txt
verbosity=1
bootlogo=false
console=both
disp_mode=1920x1080p60
overlay_prefix=sun50i-orangepizero2-3
rootdev=UUID=8b58b731-6024-4fbe-bd3e-c784b3b9a449
rootfstype=ext4
overlays=i2c3 ir otg-host spi1-cs0-spidev uart5
usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u
 
Armbian-config creates and modifies this line when you enable/disable overlays.
 
If that resolves the problem try adding overlays one at a time. I would suggest this order:
i2c3
ir
spi1-cs0-spidev
uart5
otg-host

@pixdrift You will need a connection to the console uart to catch the log of the overlays. It all happens at boot time before the OS is started.
On the system as root go to armbian-config and then System and Hardware. enable (space) all of the items offered. Then save, back and reboot. Watch the output of the console.
 
U-Boot 2024.01-rc5-armbian (Dec 31 2023 - 01:13:07 +0000) Allwinner Technology
CPU:   Allwinner H616 (SUN50I)
Model: OrangePi Zero3
DRAM:  1 GiB
Core:  57 devices, 25 uclasses, devicetree: separate
WDT:   Not starting watchdog@30090a0
MMC:   mmc@4020000: 0
Loading Environment from FAT... Unable to use mmc 0:1...
In:    serial@5000000
Out:   serial@5000000
Err:   serial@5000000
Allwinner mUSB OTG (Peripheral)
Net:   Unsupported value 13, using default (13)
Unsupported value 13, using default (13)
eth0: ethernet@5020000using musb-hdrc, OUT ep1out IN ep1in STATUS ep2in
MAC de:ad:be:ef:00:01
HOST MAC de:ad:be:ef:00:00
RNDIS ready
, eth1: usb_ether
starting USB...
Bus usb@5200000: USB EHCI 1.00
Bus usb@5200400: USB OHCI 1.0
scanning bus usb@5200000 for devices... 1 USB Device(s) found
scanning bus usb@5200400 for devices... 1 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found
Autoboot in 1 seconds, press <Space> to stop
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot/boot.scr
3259 bytes read in 2 ms (1.6 MiB/s)
## Executing script at 4fc00000
U-boot loaded from SD
Boot script loaded from mmc
299 bytes read in 2 ms (145.5 KiB/s)
31257 bytes read in 4 ms (7.5 MiB/s)
Working FDT set to 4fa00000
268 bytes read in 3 ms (86.9 KiB/s)
Applying kernel provided DT overlay sun50i-h616-ir.dtbo
512 bytes read in 3 ms (166 KiB/s)
Applying kernel provided DT overlay sun50i-h616-light.dtbo
failed on fdt_overlay_apply(): FDT_ERR_NOTFOUND
339 bytes read in 3 ms (110.4 KiB/s)
Applying kernel provided DT overlay sun50i-h616-mcp2515.dtbo

I have a zero3 with 1G ram. I just stuck some small heats sinks on the cpu and mem. A stress test and results are included below.
Before Armbian was viable I compiled the Linux kernel on this system using the Zunlong image.  It ran for a couple of hours with all 4 cpus at 100%.  The temperature stayed constant at about 65, but it worked without a problem.
 
sysadmin@orangepizero3:~$ sudo stress --cpu 4 --io 4 -m 4 --vm-bytes 256M -t 300
stress: info: [2144] dispatching hogs: 4 cpu, 4 io, 4 vm, 0 hdd
stress: info: [2144] successful run completed in 301s
 
12:07:25   480 MHz  3.60   0%   0%   0%   0%   0%   0%  41.3 °C  0/5
12:07:31   480 MHz  3.39   0%   0%   0%   0%   0%   0%  41.3 °C  0/5
12:07:36  1512 MHz  3.20  22%  15%   7%   0%   0%   0%  43.8 °C  0/5
12:07:41  1512 MHz  4.07 100%  64%  35%   0%   0%   0%  48.0 °C  0/5
12:07:46  1512 MHz  4.78 100%  64%  35%   0%   0%   0%  48.7 °C  0/5
12:07:51  1512 MHz  5.44 100%  64%  35%   0%   0%   0%  49.3 °C  0/5
...
12:12:09  1512 MHz 13.22 100%  66%  33%   0%   0%   0%  56.7 °C  0/5
12:12:14  1512 MHz 13.20 100%  64%  35%   0%   0%   0%  56.5 °C  0/5
12:12:19  1512 MHz 13.18 100%  65%  34%   0%   0%   0%  56.4 °C  0/5
Time        CPU    load %cpu %sys %usr %nice %io %irq   Tcpu  C.St.
12:12:25  1512 MHz 13.17 100%  64%  35%   0%   0%   0%  57.0 °C  0/5
12:12:30  1512 MHz 13.16 100%  65%  34%   0%   0%   0%  56.8 °C  0/5
12:12:35  1512 MHz 13.14  96%  62%  30%   0%   3%   0%  56.8 °C  0/5
12:12:40   480 MHz 12.17   0%   0%   0%   0%   0%   0%  51.0 °C  0/5
12:12:45   480 MHz 11.28   0%   0%   0%   0%   0%   0%  49.9 °C  0/5
12:12:50   480 MHz 10.45   0%   0%   0%   0%   0%   0%  49.1 °C  0/5
12:12:55   480 MHz  9.69   0%   0%   0%   0%   0%   0%  48.4 °C  0/5
...
12:56:56   480 MHz  1.00   0%   0%   0%   0%   0%   0%  39.1 °C  0/5
12:57:01   480 MHz  1.08   0%   0%   0%   0%   0%   0%  39.5 °C  0/5
12:57:06   480 MHz  1.07   0%   0%   0%   0%   0%   0%  39.3 °C  0/5
12:57:11   480 MHz  1.06   0%   0%   0%   0%   0%   0%  39.2 °C  0/5

@Gunjan Gupta, Would you be able move forward the following patch. I have been working on the zero3 overlays and with your help I have made some progress. But it all depends on having the overlay_prefix set.  It makes sense to point to the h616 overlays as the zero3 and zero2 are common for the items that would normally go into the overlays. I have been using the proposed change and it makes the fixup.scr work on boot and allows armbian-config > System > Hardware to work and load overlays on boot
 
diff --git a/config/boards/orangepizero3.wip b/config/boards/orangepizero3.wip
index 18bcae79d..642eb216f 100644
--- a/config/boards/orangepizero3.wip
+++ b/config/boards/orangepizero3.wip
@@ -3,6 +3,7 @@ BOARD_NAME="Orange Pi Zero3"
 BOARDFAMILY="sun50iw9"
 BOARD_MAINTAINER="viraniac"
 BOOTCONFIG="orangepi_zero3_defconfig"
+OVERLAY_PREFIX=sun50i-h616
 BOOT_LOGO="desktop"
 KERNEL_TARGET="current,edge"
 FORCE_BOOTSCRIPT_UPDATE="yes"
 

I think the overlay files for zero2 and zero3 can be the same as the hardware layout is identical. Zero2w is different.
I have put together and tested 3 overlay files,
- enable i2c3
- enable spi1 and create spidev
- change usbotg to host
I could use the i2c3 and spi1 overlays to fix the PH5 duplication if it will not be done in sun50i-h616.dtsi.
Usb2 and 3 are already enabled and work without further changes.
I am still looking into uart5 to determine what is required. Ir is another item to look at.  Then there is sound which has output on the header. But since sound is not yet working that will have to wait.
All these overlays currently exist in the Zunlong image. After @Gunjan Gupta showed me how to build an overlay I am now able to reverse engineer the Zunlong dtbos and create dts/dtbo for Armbian.

@Gunjan Gupta, Would you be able move forward the following patch. I have been working on the zero3 overlays and with your help I have made some progress. But it all depends on having the overlay_prefix set.  It makes sense to point to the h616 overlays as the zero3 and zero2 are common for the items that would normally go into the overlays. I have been using the proposed change and it makes the fixup.scr work on boot and allows armbian-config > System > Hardware to work and load overlays on boot
 
diff --git a/config/boards/orangepizero3.wip b/config/boards/orangepizero3.wip
index 18bcae79d..642eb216f 100644
--- a/config/boards/orangepizero3.wip
+++ b/config/boards/orangepizero3.wip
@@ -3,6 +3,7 @@ BOARD_NAME="Orange Pi Zero3"
 BOARDFAMILY="sun50iw9"
 BOARD_MAINTAINER="viraniac"
 BOOTCONFIG="orangepi_zero3_defconfig"
+OVERLAY_PREFIX=sun50i-h616
 BOOT_LOGO="desktop"
 KERNEL_TARGET="current,edge"
 FORCE_BOOTSCRIPT_UPDATE="yes"
 

@Gunjan Gupta No offence taken.  I am always impressed by people who have to communicate in a language other than their native. Keep giving me advice and I will keep trying to learn.
 
In that respect can you tell me why this dts does not compile:
 
sysadmin@orangepizero3:/mnt/dtbo$ dtc -O dtb -o sun50i-h616-i2c3.dtbo sun50i-h616-i2c3.dts
sun50i-h616-i2c3.dts:19.29-23.19: ERROR (phandle_references): /fragment@1/__overlay__: Reference to non-existent node or label "i2c3_ph_pins"
ERROR: Input tree has errors, aborting (use -f to force output)
sysadmin@orangepizero3:/mnt/dtbo$ more sun50i-h616-i2c3.dts
/dts-v1/;
/ {
        compatible = "allwinner,sun50i-h616";
        fragment@0 {
                target-path = "/aliases";
                __overlay__ {
                        i2c3 = "/soc/i2c@5002c00";
                        i2c3_ph_pins = "/soc/pinctrl@300b000/i2c3-ph-pins";
                };
        };

        fragment@1 {
                target = <0xffffffff>;
                __overlay__ {
                        status = "okay";
                        pinctrl-names = "default";
                        pinctrl-0 = <&i2c3_ph_pins>;
                };
        };
        __fixups__ {
                i2c3 = "/fragment@1:target:0";
        };
};
 
 

@Gunjan Gupta No offence taken.  I am always impressed by people who have to communicate in a language other than their native. Keep giving me advice and I will keep trying to learn.
 
In that respect can you tell me why this dts does not compile:
 
sysadmin@orangepizero3:/mnt/dtbo$ dtc -O dtb -o sun50i-h616-i2c3.dtbo sun50i-h616-i2c3.dts
sun50i-h616-i2c3.dts:19.29-23.19: ERROR (phandle_references): /fragment@1/__overlay__: Reference to non-existent node or label "i2c3_ph_pins"
ERROR: Input tree has errors, aborting (use -f to force output)
sysadmin@orangepizero3:/mnt/dtbo$ more sun50i-h616-i2c3.dts
/dts-v1/;
/ {
        compatible = "allwinner,sun50i-h616";
        fragment@0 {
                target-path = "/aliases";
                __overlay__ {
                        i2c3 = "/soc/i2c@5002c00";
                        i2c3_ph_pins = "/soc/pinctrl@300b000/i2c3-ph-pins";
                };
        };

        fragment@1 {
                target = <0xffffffff>;
                __overlay__ {
                        status = "okay";
                        pinctrl-names = "default";
                        pinctrl-0 = <&i2c3_ph_pins>;
                };
        };
        __fixups__ {
                i2c3 = "/fragment@1:target:0";
        };
};
 
 

I just finished testing with the build you supplied and it worked as expected.  I have a temperature & pressure sensor on an 12c device that I connect to the zero3 header and then read it with rust code.
There are i2c tools installed on the image that you can use to interrogate the i2c system:
 
root@orangepizero3:~# i2cdetect -l
i2c-0   i2c             mv64xxx_i2c adapter                     I2C adapter
i2c-1   i2c             DesignWare HDMI                         I2C adapter
i2c-2   i2c             mv64xxx_i2c adapter                     I2C adapter
root@orangepizero3:~# i2cdetect 2
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-2.
I will probe address range 0x08-0x77.
Continue? [Y/n] y
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- 38 -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
root@orangepizero3:~#
 
I think there are 2 i2c systems used internally by the zero3.  The i2c3 that we are working on became i2c-2 as enumerated by linux. My device shows up as address 38 on the scan.
 
Thank you for your work adding the patch.

@pixdrift, @Gunjan Gupta I built an image by getting  a repository:
git clone https://github.com/viraniac/armbian_build.git.
The image works with HDMI using my brand new cable that arrived less than an hour ago.
I will test more later.  Is this a good way to produce an image? I'm not quite sure.

The comment in mmc0 is in the original dts from linux and has not caused any problems that I know of so far.

Both the wifi and HDMI work should be common to both the zero2 and zero3 and possibly the zero2w.  Would it be possible to work in an environment that supports both?