Gunjan Gupta

overlays are generally soc specific and allow a specific functionality to be enabled or disabled. For example, you can think of creating an overlay that will enable all things are are available on headers of zero3, but then as Stephen pointed out, some pins will be used in more than one functionality. Also to add it it, a person using the header might need only one i2c or just the pwm or some other single functionality while needing rest of the pins to continue working as single gpio. Hence creating a board specific overlay that enables everything is not a solution. You can however create overlays enabling multiple functionalities needed for an addon board/hat. This will be ok as only people having that addon board will enable the same. For example all the functionality exposed by addon board used on the 13-pin header like usb, tv-out, ir, audio must be combined into a single dtoverlay and should not be enabled by default on the device. So we do have some extra things enabled that we need to get rid of from dts and move to seperate overlay.

I see SPI1_CS1 is PH9 for zero2w as well based on the schematics made available by orange pi. Why do you feel its different?

Thats becuase loading overlays from configfs is something that was viewed as not a recommended way and hence was not merged into the kernel. If you still wants to do the same, I believe our Allwinner kernels do have a patch that adds that functionality. Not sure if the same can be said for every soc family supported by Armbian. Also I am not sure if loading overlay via configfs is ever tested and hence cant say how well that works.

The above will compile and should work fine. If you will then decompile it you will get the overlay in fragment syntax

Honestly I have never used the fragment syntax. Just use the following for your overlay /dts-v1/; /plugin/; &i2c3 { status = "okay"; pinctrl-names = "default"; pinctrl-0 = <&i2c3_ph_pins>; };

I will suggest you go through https://bootlin.com/blog/using-device-tree-overlays-example-on-beaglebone-boards/ once. It helped me a lot when I was learning about device trees and overlays

I noticed you are adding something to alias. Aliases are autogenerated. If something doesnt have an alias, you can use its full path for refering the same. For example, pinctrl-0 = <&i2c3_ph_pins>; Can be changed to pinctrl-0 = <&{/soc/pinctrl@300b000/i2c3-ph-pins}>; You also seems to be missing /plugin/; This should be placed after /dts-v1/;

You are missing -@ in the commandline. It should be dtc -@ -O dtb -I dts -o sun50i-h616-i2c3.dtbo sun50i-h616-i2c3.dts. There is also a shortcut if you like to take it. Just run armbian-add-overlay <dts_file_name>. It will automatically compile the overlay, copy it to necessary directory and add the corresponding entry in /boot/armbianEnv.txt file

Sorry if I sounded rude. Any statement I post is direct translation done in my head from my native language. Thats how I talk to anyone and everyone. Any hint of arrogance is not intended and just there due to my lack of english speaking skills and social skills. I am not really a social person.

May be because they were added for Bigtreetech CB1 Why would it change the dtb? That would defeat the whole purpose of having overlays. Overlays are applied at runtime. If you want to check if your changes are applied, you can verify the same by reading i2c related files in /proc/device-tree There is no need to use that fragment syntax. There is much simpler way to do the same almost identical to writing dts files. Check https://bootlin.com/blog/using-device-tree-overlays-example-on-beaglebone-boards/

I will advice to add that as an overlay. Its an optional functionality and its possible someone might just use those pins for gpio ir not use them at all. The currently present overlays for H616 are some overlays that were added for bigtreetech cb1 coming from https://github.com/armbian/build/blob/main/patch/kernel/archive/sunxi-6.7/patches.armbian/arm64-dts-overlay-sun50i-h616-bigtreetech-cb1.patch Let me know if you need any help with cretaing overlay files

Yes, thats correct

As h616 and h618 are suppose to be pin compatible, same overlays should work between the same

Its generated based on the options specified in the board config file. You can add OVERLAY_PREFIX=sun50i-h616 in orangepizero3.conf and that should get replicated in armbianEnv.txt in your next build

Its possible armbian-config might be looking for files starting with sun50i-h618 as that is the compatible string in zero3.dts. Try adding symlinks or renaming h616 overlay files present in /boot/dtb/overlay and see if armbian-config starts listing those files

To debug the problem first we need to know about your setup and the steps to produce the problem. Apart from knowing that you are probably using Orange Pi 3 LTS, we know nothing about your setup. Like what image you are using and what kernel version you are on. Also there doesn't seem to be any logs shared. Please use armbianmonitor -u and share the url. If network is not available, you can also use armbianmonitor -U to dump logs to console and then share the same manually.

Your patch seems to be base of https://lore.kernel.org/all/20231128005849.19044-1-andre.przywara@arm.com/ as well. Though there is no reference in the patch series that it came from your patch

@pixdriftLets just patch dts instead of patching driver. I think that is the better solution

Looks ok, but its just a diff and is not in git format-patch format similar to other patches. Also instead of saying blocklist, it should be something like add h618 to matchlist Use ./compile BOARD=orangepizero3 BRANCH=current kernel-patch to create the patch

Feel free to add a patch and test it out. Its a single line change after all. I won't be working on this for next few days as I am busy with some other things

I remember a discussion where Cornelius reported similar issue with some H5 board. He said that problem was being caused by sun8i-a33-mbus module. Does blacklisting the same makes things better?

fizban, I haven't tried HW acceleration on allwinner boards, but generally you will need specially patched libraries that can support v4l2 request api for it to work. Armbian doesn't ship them by default

I don't have a zero2. I only bought a zero3

Interact how? you are trying to ssh or something? If ping works, I fail to see why other things won't

@sagard , you can combine dts compilation, copying and then editing of armbianEnv.txt into single command - armbian-add-overlay <dts_file_name>