Image | Orange Pi Zero 2W

[jamsinclair]

Creating an image request

Formal device information

• Device name | Orange Pi Zero 2W
• Official product URL | http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/service-and-support/Orange-Pi-Zero-2W.html
• GitHub resource URL (if available) | https://github.com/orangepi-xunlong
• Image download URL | Google Drive Link – There's different images depending on the RAM installed, 1-2GB RAM, 1.5GB RAM and 4GB RAM.

Is the SBC officially supported by the Debian installer?

• No

If not, is a reliable 3rd party Debian image available for this SBC?

• Kind of, made by the manufacturer (see image download URL)

If not, are there install instructions for Debian available?

---

I see previous issues that requested an Orange Pi image had been closed. If this is still the case, feel free to close this issue 🙇

[jamsinclair]

I tried making my own distribution, following the guide, however, I couldn't get the created image working on the device. I can only connect headlessly over wifi to the device, so this may have been the overall issue 😅

Looking at the specs between the OPi Zero 3 and the OPI Zero 2W there's a lot of similar components used, I've just flashed the Zero 3 image to my device and it seems to be working ok so far... 🤞 and the wifi definitely works – due to my reliance on headless setup.

	OPi Zero 3	OPi Zero 2W
CPU	Allwinner H618 Quad-core Cortex-A53 processor 1.5GHz	Allwinner H618 Quad-core Cortex-A53 processor 1.5GHz	✅
GPU	Mali G31 MP2	Mali G31 MP2	✅
Memory	1GB/1.5GB/2GB/4GB LPDDR4	1GB/1.5GB/2GB/4GB LPDDR4	✅
On-board storage	16MB SPI Flash	16MB SPI Flash	✅

Are there any other board features that we should care about that might affect the usage of the Zero 3 image on the Zero 2W? On paper they look pretty similar, the only difference really being their form factor and the Zero 3 having some additional physical I/O, like ethernet.

Edit: it seems like there's already a lot discussion over in #6594

Edit 2: (5 Jan 2024) I've been using the Orange Pi Zero 3 image successfully for a week now with no issues. It's only connected via WiFi. I have successfully been using software like Tailscale, NFS network drive etc with it.

[deftdawg]

I'm also using the OPi Zero 3 dietpi image on an OPi Zero 2W, only issue I've had is some instability because of thermals (system hot to the touch when it crashed).

I changed the Governor to max out at 1008Mhz (down from 1502Mhz) and that seems to have stabilised the system.

[MichaIng]

It actually makes sense, since the kernel/dtb package contains device trees for the Zero 2 and Zero 2W as well:

The bootloader is Zero 3 specific, but since it is the same SoC/RAM/SPI flash, it makes sense that this works as well on Zero 2. And after the kernel booted, the bootloader is not relevant anymore.

Only one thing would be good to check: Does the bootloader enforce the Zero 3 device tree or does it choose the correct one based on the actual model:

cat /proc/device-tree/model

Does someone have a Zero 2 non-W and can check whether it is the same issue with the Ethernet adapter disappearing on reboot?

[jamsinclair]

Only one thing would be good to check: Does the bootloader enforce the Zero 3 device tree or does it choose the correct one based on the actual model:

cat /proc/device-tree/model

@MichaIng it doesn't seem to. Running this from an OPi Zero 2W it returns OrangePi Zero3.

Are there any quick workaround to selecting the correct device tree during the bootload (or after the fact)?

[MichaIng]

Try the following:

G_CONFIG_INJECT 'fdtfile=' 'fdtfile=allwinner/sun50i-h616-orangepi-zero2w.dtb' /boot/dietpiEnv.txt
reboot

[jamsinclair]

Thanks for the quick response! That makes sense, I'll be away from my OPi for a couple of weeks. If someone else can confirm in the interim, go ahead!

[deftdawg]

G_CONFIG_INJECT said I didn't have permissions, when I prefixed with sudo command wasn't found. So applied the change with sudo nano and rebooted.

dietpi@DietPi:~$ cat /proc/device-tree/model
OrangePi Zero2 W

One thing I noticed is that with this Zero2 W booted with the proper config my dual nic carrier board doesn't work properly (nics light up, but don't work, stay lit after disconnecting Ethernet). Reverting dietpiEnv.txt and rebooting restores function of the nics.

The carrier board connects via 4 pogo pins to the middle USB port (visible around green led)

As an aside, the following message is present regardless which dtb is used

-
[
57.0884801 sproul:wlan_delba_event: NOT FOUND sta_lut_index: 6, tid: 4
57.107166]
sprowl:wlan_delba_event: NOT FOUND
sta_lut_index: 6, tid: 5
57. 109182)
sprdul: wlan_delba_event: NOT FOUND sta_lut_index: 6,
_index: 6, tid: 6
57.1159271 sprdwl: wlan_delba_event: NOT FOUND sta_lut_index: 6, tid: 7

[jamsinclair]

Back in business 💼

Following @MichaIng's instruction

• Switched to the root user
• Ran the command to modify the /boot/dietpiEnv.txt file
• Rebooted the device

The device on boot now reports the correct device tree:

$ cat /proc/device-tree/model
OrangePi Zero2 W

[deftdawg]

I still don't get why the carrier board (which is a usb hub connected over pogo pins) would work fine out of the box with the OrangePi Zero 3 device tree but not work at all with the OrangePi Zero 2 W tree.

[MichaIng]

I still don't get why the carrier board (which is a usb hub connected over pogo pins) would work fine out of the box with the OrangePi Zero 3 device tree but not work at all with the OrangePi Zero 2 W tree.

Hmm, that is nasty indeed 🤔.

[samjw-nz]

Can confirm the Orange Pi Zero 3 image DOES technically work on the Zero 2W, however I can't get GPIO serial to work. I'm trying to use the Zero 2W as an Octoprint board in my Prusa, and can't get it working on any of the 5 GPIO serial connections. No issue with DietPi-Software or any of the typical usage stuff, but for the life of me I can't get communication working.
Having an attempt with converting the OrangePi image to DietPi but haven't gotten far yet.

[MichaIng]

Some someone else test/verify this: https://dietpi.com/forum/t/manually-install-wifi-package-or-firmware-file/13182/21?u=michaing

• Bluetooth only works when WiFi is enabled as well. Or more precisely, the modprobe sprdbt_tty fails as long as modprobe sprdwl_ng has not been loaded.
• Loading sprdwl_ng via /etc/modules-load.d/ at boot time fails, but it can be loaded later from console via modprobe.

[samjw-nz]

Reckon I can give this a test this week. Do you have any example tests / commands I can use to verify? I'm not experienced with testing these things and don't currently have a bluetooth use-case, I'm just a user who just happens to own the hardware and have some time to chip in.

[srimanachanta]

I installed the Orange Pi Zero 3 image on my Zero 2W and when running i2c-detect over the ports (should be i2c-1 on zero 2w so im checking i2c-3 on the zero3) my device isn't connected. I have went ahead and checked all other ports (0 and 1 are present when checking /dev/i2c* but also 2, 3, and 4.

Also, when modifying /boot/dietpiEnv.txt to set the dtb file to zero2w, it doesn't work, and after checking the dtb directory, only the file for zero3 is present.

[el-bakkali]

I have the same issue,

I ran Michael command as recommended, and after reboot i can no longer ssh into the device.

As mentioned the zero2w dtb files does not exist in the dtb directory

Since this device uses the same chip as zero3 , it would be nice to have a universal image for it
same way we do for raspberry pi etc.
as the saying goes it will kill two bird with one stone.

[srimanachanta]

Orange Pi supplies a Debian image here. Im going to install that and then install DietPi using these docs. Hopefully, that works better.

[srimanachanta]

I have the same issue,

I ran Michael command as recommended, and after reboot i can no longer ssh into the device.

As mentioned the zero2w dtb files does not exist in the dtb directory

Since this device uses the same chip as zero3 , it would be nice to have a universal image for it same way we do for raspberry pi etc. as the saying goes it will kill two bird with one stone.

I think the issue with a universal issue is that they have different IOs and bus-to-pin layouts. I'm not super knowledgeable on the DietPi system though, so I may be wrong here.

[MichaIng]

Without a matching device tree, most hardware features won't work, simple as that. And indeed, the latest kernel build does not contain a Zero 2W device tree anymore:

Not sure why it was present in the first place. Mainline Linux 6.6 does not contain it either: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/boot/dts/allwinner?h=linux-6.6.y
But Linux 6.8 added one: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/boot/dts/allwinner?h=linux-6.8.y

• https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit?id=c505ee1

There is already a draft at Armbian to add support based on this DTB: armbian/build#6451

Allwinner edge kernel builds with Armbian are still Linux 6.7, otherwise we would not need to wait for the PR: https://github.com/armbian/build/blob/main/config/sources/families/include/sunxi64_common.inc

I just started builds based on this PR:

• https://github.com/MichaIng/DietPi/actions/runs/8491375886/job/23263287258
• https://github.com/MichaIng/DietPi/actions/runs/8491377766/job/23263290664

[srimanachanta]

Is there is an Image I can test with? I don't see any artifacts under those builds unless I'm just blind lol.

[Joulinar]

There is no image yet.

[MichaIng]

These were kernel and bootloader builds. I triggered an image build here: https://github.com/MichaIng/DietPi/actions/runs/8491738902/job/23264002541

It can be found here once done: https://dietpi.com/downloads/images/testing/

[srimanachanta]

These were kernel and bootloader builds. I triggered an image build here: https://github.com/MichaIng/DietPi/actions/runs/8491738902/job/23264002541

It can be found here once done: https://dietpi.com/downloads/images/testing/

Thank you, I will test that out after its done and report back

[MichaIng]

Btw, the SBC has no GPIO header exposed by default, but it can be soldered onto the PCB to be usable? I.e. does it make sense to enable a UART console by default, and e.g. expose the SPI toggle we added for Orange Pi Zero 3?

Or does it support USB UART on one of the USB ports in OTG/gadget mode?

[srimanachanta]

Btw, the SBC has no GPIO header exposed by default, but it can be soldered onto the PCB to be usable? I.e. does it make sense to enable a UART console by default, and e.g. expose the SPI toggle we added for Orange Pi Zero 3?

Or does it support USB UART on one of the USB ports in OTG/gadget mode?

Not sure about the latter part but yes, it includes a 2x20 header set that I had to solder on the SBC. I think UART console should be left the same as the OPI Zero3 because people are already prompted to disable it if they aren't using it. I also thing its supported over USB but regardless, prob just leave it on.

[srimanachanta]

@MichaIng Seems the build failed, I don't think an artifact was uploaded either.

[MichaIng]

Yes, I forgot to move the bootloader package in place. It is rerunning.

Okay, I'll enable /dev/ttyS0 then. Would still be great to have some feedback of someone actually using it, and e.g. as well SPI 🙂.

[MichaIng]

Your logs show an abrupt switch from one armbian-firmware package upgrade to another dietpi-software execution:

Unpacking armbian-firmware (24.5.1) over (24.5.0-trunk) ...
[      ] DietPi-Software | Initialising database

Then, of course the package configuration is missing and you need to run dpkg --configure -a once, as stated in the error message.

Did you face another error during the very first dietpi-software execution on first login or interrupted that one with e.g. CTRL+C?

Or data sync to the disk did not finish as expected. I just added some sync calls before reboots as failsafe steps: a3a4b37
It should not be required, but it does not hurt after kernel upgrades and partition or filesystem expansions, where essential metadata or files were changed.

[LiminalD]

I have tried to do a new install. I only use Wi-Fi (so I do all settings via the config files) since this should be possible. The problem is that it disconnects even before the changes can be installed. Is it possible to add the changes directly to the image?

[MichaIng]

The problem is that it disconnects even before the changes can be installed. Is it possible to add the changes directly to the image?

Does it crash? That would of course explain it as well. A package upgrade however should not crash the device, of course. Do you have a good PSU with some backup power?

However, urostor on the forum reported crashes as well, when having HDMI connected. So it seems to not be 100% stable yet. I'll do a rebuild with the new kernel. Let's see whether it helps.

https://github.com/MichaIng/DietPi/actions/runs/9357419241
Can be found here, once done: https://dietpi.com/downloads/images/testing/

[LiminalD]

It is working flawlessly so far! No issues, no crashes. I will keep it running and let you know if anything comes up.

[mtojek]

Hi @MichaIng,

I'm fighting with OPi Zero 2w and migration from the original OrangePi firmware. Unfortunately, I can't make BT running:

root@DietPi:/home/dietpi# service bluetooth status
○ bluetooth.service - Bluetooth service
     Loaded: loaded (/lib/systemd/system/bluetooth.service; enabled; preset: enabled)
     Active: inactive (dead)
       Docs: man:bluetoothd(8)

Jun 04 14:12:49 DietPi systemd[1]: bluetooth.service - Bluetooth service was skipped because of an unmet condition check (ConditionPathIsDirectory=/sys/class/bluetooth).

Once started (somehow):

root@DietPi:/home/dietpi# bluetoothctl scan on
No default controller available

I tried modprobe -r sprdbt_tty && modprobe sprdbt_tty, but it causes segmentation fault.

Does BT work for Zero 2W today?

EDIT:

Turning it on/off also ends up with segfault:

Get:1 https://deb.debian.org/debian bookworm/main arm64 libdw1 arm64 0.188-2.1 [219 kB]
Get:2 https://deb.debian.org/debian bookworm/main arm64 bluez arm64 5.66-1+deb12u1 [1062 kB]
debconf: delaying package configuration, since apt-utils is not installed
Fetched 1281 kB in 1s (2324 kB/s)
                                 Selecting previously unselected package libdw1:arm64.
(Reading database ... 46125 files and directories currently installed.)
Preparing to unpack .../libdw1_0.188-2.1_arm64.deb ...
Unpacking libdw1:arm64 (0.188-2.1) ...
Selecting previously unselected package bluez.
Preparing to unpack .../bluez_5.66-1+deb12u1_arm64.deb ...
Unpacking bluez (5.66-1+deb12u1) ...
Setting up libdw1:arm64 (0.188-2.1) ...
Setting up bluez (5.66-1+deb12u1) ...
Created symlink /etc/systemd/system/dbus-org.bluez.service → /lib/systemd/system/bluetooth.service.
Created symlink /etc/systemd/system/bluetooth.target.wants/bluetooth.service → /lib/systemd/system/bluetooth.service.
Processing triggers for libc-bin (2.36-9+deb12u7) ...
Processing triggers for dbus (1.14.10-1~deb12u1) ...
[  OK  ] DietPi-Set_hardware | APT install bluez
/boot/dietpi/func/dietpi-set_hardware: line 1245:  2738 Segmentation fault      modprobe "$i" 2> /dev/null

[MichaIng]

So this module seems to have the same as sprdwl_ng, so that it cannot be unloaded and re-loaded, but requires a reboot to work. Actually, does only unloading and loading it cause issues, like the segmentation faul, or does also loading it at this later boot stage cause issues, when it has never been loaded in a boot session before?

Strange is, that the command and line which throws the segmentation fault of your last log is not loading sprdwl_ng, but another set of modules for Bluetooth, mostly for other SBCs. Can you check which one throws this?

modprobe bluetooth
modprobe bnep
modprobe btbcm
modprobe rfcomm
modprobe hidp
modprobe hci_uart

This is from old times, and I actually don't think that any of this is still required, but modules are usually loaded on demand, in all cases but this particular sprdbt_tty and sprdwl_ng, which is why we load them at every boot, when WiFi/BT is enabled, via:

ls /etc/modules-load.d/dietpi-enable_bluetooth.conf

Has this file been created in your case, or was the script aborted at the segmentation faul? If the file does not exist, please create it:

echo 'sprdbt_tty' > /etc/modules-load.d/dietpi-enable_bluetooth.conf

Then reboot and see whether the Bluetooth service does now start up:

journalctl -u bluetooth

[mtojek]

I applied the following workaround to make it working:

1. Run curl -sSfo /usr/local/bin/hciattach_opi 'https://raw.githubusercontent.com/armbian/build/main/packages/bsp/rk3399/hciattach_opi'

2. Run chmod +x /usr/local/bin/hciattach_opi

3. Create file /etc/systemd/system/sprd-bluetooth.service:

[Unit]
Description=Spreadtrum (sprd) bluetooth support
Before=bluetooth.service

[Service]
RemainAfterExit=yes
ExecStartPre=/bin/sleep 60
ExecStartPre=/usr/sbin/modprobe sprdwl_ng
ExecStartPre=/usr/sbin/modprobe sprdbt_tty
ExecStart=/usr/local/bin/hciattach_opi -n -s 1500000 /dev/ttyBT0 sprd

[Install]
WantedBy=multi-user.target

4. Enable service with systemctl enable --now sprd-bluetooth.

Do you know why hciattach_opi was crucial here?

[MichaIng]

Ah right, I remember some Orange Pi's require this HCI-UART attach blob. Generally some SBCs have Bluetooth internally attached to one of the UART devices. Same on RPi, the hciuart.service is required, and some use(d) this hci_uart kernel module.

Same is true for Orange Pi 3B, and I guess for Zero 3 as well then. I'll implement this for all 3 of them.

Is the sprdwl_ng module really required, or does it work as well when removing ExecStartPre=/usr/sbin/modprobe sprdwl_ng? Similarly, is it required to wait for 60 seconds?

bluez itself ships /usr/bin/hciattach, but it does not work in those cases, does it? https://manpages.debian.org/hciattach

[mtojek]

Hey, I moved forward and stopped at configuring i2s on OPi Zero 2w.

Let me cross-post the issue here:

[    9.671505] [sound  231][AHUB_DAM snd_soc_sunxi_ahub_mem_get] regmap is invalid
[    9.671520] [sound 1342][AHUB sunxi_ahub_dev_probe] remap get failed
[    9.671526] sunxi-snd-plat-ahub: probe of soc:ahub0_plat failed with error -22

Has anyone successfully connected the sound card using regular pins?

[MichaIng]

Like so many other things, it works when using the Zero 3 device tree (assuming that your HAT/DAC uses the same native analogue audio form GPIO pins) 😄: https://dietpi.com/forum/t/no-sound-card-detected-for-opi-zero-2w/20133

Not sure why, but the Zero 2W device tree seems to be a mess. While the Zero 3 one just worked OOTB, with just minor GPIO related limitations, the Zero 2W one hat a lot of issues, and obviously, not all of them have been solved yet.

If anyone has enough experience and time+mood, it could make a lot of sense to rebuild that device tree, using the Zero 3 ones as basis.

EDIT: Ah, not sure which kernel sources/builds you use, but here is the PR at Armbian, including DTS patch, which enabled this support for H616/H618 chips, just not functional with the Zero 2W device tree they and us use: armbian/build#6694

[mtojek]

Yeah, I saw this post or rather the idea, but I'm not sure how to sort out my case:

1. I'm using i2s0 instead of i2s3 - technically shouldn't be the problem right?
2. I don't have the expansion board, just depend on my own sound card.

Ah, not sure which kernel sources/builds you use, but here is the PR at Armbian, including DTS patch, which enabled this support for H616/H618 chips, just not functional with the Zero 2W device tree they and us use

I'm on:

Linux DietPi 6.6.31-current-sunxi64 #1 SMP Fri May 17 10:02:40 UTC 2024 aarch64 GNU/Linux
armbian-firmware is already the newest version (24.5.1).

[MichaIng]

With this commit, there was no overlay needed anymore, as said, it worked just OOTB (as far as I understood, and since I gave instructions to remove the overlay). As far as I understood, this HAT uses an onboard sound chip, just exposed via GPIO pins.

I don't have the expansion board, just depend on my own sound card.

Ah okay, then things are likely different. The Armbian kernel provides overlays to enable I2C 0-4:

Hence requires an overlays=i2c0-pi entry in the armbianEnv.txt/dietpiEnv.txt, with overlay_prefix=sun50i-h616.

[mtojek]

Armbian kernel provides overlays to enable I2C 0-4:

Thanks for bringing this up. Actually, I need i2s not i2c :)

[MichaIng]

Ah right sorry, of course I2S, which is also why the guy from the forum tried an own overlay he found online.

[Totof34]

Hello mtojek and Micha
good news to know i'm not alone for i2s

What i know is that the i2s0 is reserved for HDMI on the main board and the expansion board use direct output from the H618 on pin G19 and G20 via the 24 pin connector for the jack connector

like you mtojek i want to use i2s for a pcm5102 via the 40 pin HAT connector
In the datasheet of the H618 via the zero3 board you can find the pin 19(ph7), 21(ph8) and 23 (ph6) for i2s3
and also on the zero2w schématic under the spi1 overlay

Have you try to write your overlay with the i2s3 map

cordialy

[mtojek]

I'm afraid that there is an issue with 6.6 kernel. I managed to get i2s0 working for orangepi-xunlong image with 6.1 kernel using this dts. My hunch is that dts is correctish.. but the driver may not be stable.

[Totof34]

This would be very good news because the pins of the i2s0 correspond to the same pin as the rpi hat and I have several compatible dac hat to test, I would like your image to test
maybe together we'll get there

just in the back of the dts file the mention of hdmi "off"

[mtojek]

just in the back of the dts file the mention of hdmi "off"

AFAIR some pins i2s0 are in conflict with HDMI

[Totof34]

Hi

I try after work, just a question, when you tested it under orangepi image, have you the image via HDMI, and sound via i2s hat pin ?
Or you use an other video output
Have a good day

[LiminalD]

Maybe an off-topic question, but is there a complete map of the current GPIO pinout of the OPi Zero 2W that works correctly?

[Totof34]

hello mtojek
I finally try to rewrite the opizero2w.dtb with your i2s0.dts
I have some good things but no sound with the i2s0 card and i have sound with the hdmi card !!!

An idea to activate the sound on the i2s0 card

[Totof34]

hello mtojek

It works with a modified dtb file
sun50i-h618-orangepi-zero2w-with-Audiocodec-HDMI-i2s0.zip
If you would test it, i've no problem with the hdmi part
this dtb file contain sound for 3.5mm jack, HDMI and i2s0 via the hat
PI0 → I2S SCK–>pin29
PI1 → I2S BCK–>pin12
PI2 → I2S LCK–>pin35
PI3 → I2S DATA–>pin40
3.3V → to VIN power of DAC board–>pin1
GND → to GND power of DAC board-->pin6

With this dtb also the wifi and ethernet via official expansion board

I test it with Dietpi, LMS, Squeezelite and a PCM5102a

Hope it helps

[MichaIng]

That sounds great. Could you create a diff to the DTS we currently ship, at best even open a PR to adjust the patch which adds this DTS?
https://github.com/MichaIng/build/blob/dietpi/patch/kernel/archive/sunxi-6.6/patches.armbian/arm64-dts-sun50i-h618-orangepi-zero2w-add-dtb.patch

[Totof34]

Hello Micha
I can do that but i need some explication

• you would a dts file ?
  I recompile the dtb with adding a i2s0.dts compiled as dtbo and joined at the dtb file with the command
• fdtoverlay --input zero2w-essai.dtb --output zero2w-essai-i2s0.dtb sun50i-h616-i2s0.dtbo
  after i made some manual modification to your original dtb file to enable the audiocodec and HDMI
  and recompile the global dts file to a dtb

If the global dts file it's ok for you i can easely make a diff i think

[Totof34]

https://github.com/MichaIng/build/blob/dietpi/patch/kernel/archive/sunxi-6.6/patches.armbian/arm64-dts-sun50i-h618-orangepi-zero2w-add-dtb.patch

Hello Micha

I'm back home of holiday tomorrow , i took a look to fork the build repository at home

I fail to do that for now in my holiday's place

I have this message "fetch-pack: unexpected disconnect while reading sideband packet"
Perhaps the limitation of the wifi here

I tell you

[Totof34]

Hello Micha and others

I go further in the tree of the opi zero 2w, it's work perfectly with a dac like PCM5102a with the i2s0 patch

But for a dac like PCM5122 or a toslink output with WM8804 we need to activate the i2c0 or i2c1 capabilities
i can't do that with the i2c dtbo file in the source with the dtb of the opi zero 2w, i speak about the original one

Y try with
-G_CONFIG_INJECT 'overlays=' 'overlays=i2c1-pi' /boot/dietpiEnv.txt : don't work

-fdtoverlay --input zero2w.dtb --output zero2w-essai3.dtb i2c1-pi.dtbo : don't work too with an error message
the error message "Failed to apply 'i2c1-pi.dtbo': FDT_ERR_NOTFOUND" as it's incompatible version between the dtb and dtbo

The fdtoverlay works with the official dtb and dtbo of the orangepi os but this dtb doesn't work with dietpi
why ????

Many question i know, excuse me

If someone have an idea it's be helpfull

[mtojek]

The fdtoverlay works with the official dtb and dtbo of the orangepi os but this dtb doesn't work with dietpi
why ????

I came to a similar conclusion, and I would look into kernel changes between these versions.

[Totof34]

Hello mtojek

Reflexion frommy running this morning

In the dtb file i see "" compatible = "xunlong,orangepi-zero2w\0allwinner,sun50i-h618"; ""

and in the dtbo file "" compatible = "allwinner,sun50i-h616"; "" perhaps this is the problem

i try tonight and tell you

[Totof34]

Hello mtojek
i succeed to implement the i2c1 and i2s0 dtbo files with the h618 opizero2w dtb file with the file of the Armbian_community_24.8.0-trunk.369_Orangepizero2w_noble_current_6.6.36_gnome_desktop's image
So i have sound on jack,hdmi and hat with myPCM5102



But unfortunatly the pin 3 (pin7) and 5 (pin8) stay unclaimed

Would you have my last dtb file to test it ?

Other question , do you work on i2c for your personnal dac ?

I managed i2c and i2s on my opi CM4 with succes but for create a dts file for a pcm5122 dac or WM8804 transmetter
it's an other hard work