I guess the file is still in development by RPi Devs.
Dammit, even the latest kernel packages do not contain this file. And I thought that people did already successfully test it… I’ll create/copy this file in our images.
A classic “banana product”. Is sold green and then ripens at the customer. 
Indeed, pretty confusing to me after big announcement, being sold and with the RPi OS Bullseye images being released afterwards 
. I recreated images and though it would “of course” support that model then.
Quick feedback: Works now with new version. Should have been worked also with Beta 7.8.1, but I had to dis- and reanable bluetooth (which I didn’t in first place).
Thanks!
Okay great.
CassTG
How did it actually work in your case when the device tree was still missing? Did you manually copy/download the bcm2710-rpi-zero-2.dtb or was it somehow not required with the kernel/firmware you use?
For me this has not worked, i had to copy bcm2710-rpi-3-b.dtb and rename it to bcm2710-rpi-zero-2.dtb
Jep, this is what DietPi-PREP for image creation now does as well, as long as that file does not exist already.
Boot works now OOTB and it looks like BT also works. I have not really tested it, but i can discover other BT devices.
Not sure that was meant for me, i never had to download anything bar your image (32bit version)
Question was if you download/copy bcm2710-rpi-zero-2.dtb from somewhere?
See my edited response, i have never had to download anything bar the image (also booted fine from the old pi zero image)
Weird, maybe an older firmware version took the RPi 3 device tree automatically on Zero 2? Is there a kernel upgrade available?
apt upgrade
If so, and you do upgrade, prepare for being required to mount the drive elsewhere and copy bcm2710-rpi-3-b.dtb to bcm2710-rpi-zero-2.dtb.
I realized that the Zero2W is really not ready now 
MMAL Cameras for example are not working with it. I am not sure if it’s because of the 64-Bit OS or a general Bullseye problem. I wIll try With ARMv7 32Bit and see if it works.
Edit: Correction, MMAL works, but raspistill and raspivid are not supported in bullseye (only until buster). So you need the “new” libcamera apps. But libcamera does not support MMAL ATM.
Has anyone figured out, why DietPi on the Pi Zero 2W is not allowing dynamic clocking of the CPU?
The minfreq and maxfreq are both set to the same value (1000MHz default).
Changing boot.txt or installing cpufrequtils is not changing this, as cpufrequtils reports that the hardware limit is min 1000MHz and max 1000Mhz.
Overclocking is working, but the minfreq the CPU driver is allowing is always the same as the max clock.
I tried armv6 and armv7 dietpi image…same problem on both…
Current Freq Min Freq Max Freq
CPU0 | 1000 MHz 1000 MHz 1000 MHz
CPU1 | 1000 MHz 1000 MHz 1000 MHz
CPU2 | 1000 MHz 1000 MHz 1000 MHz
CPU3 | 1000 MHz 1000 MHz 1000 MHz
Edit: Just a small update (problem still exists): With the armv8 64bit Image, the dynamic cpu clock is working, as intended.
I’m also wondering why all those images produce this error while initial setup via SSH:
The setup is still running fine, but the error is still confusing.
This is known since v7.9 release. Choice/preference indices are tried to be applied directly, but before the first install, the state file does not exist yet. I’ll update respectively repack our images now to have that file pre-created.